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EXECUTIVE  SUMMARY 


The  Federal  Aviation  Administration  (FAA)  is  pursuing  an  initiative  to  develop  and 
implement  a  Data  Link  sj^tem  intended  to  enhance  communications  between  ground-based 
air  traffic  control  (ATC)  and  aircraft  operating  within  the  National  Airspace  System  (NAS). 
By  providing  digital  information  transfer  along  with  the  ability  to  discretely  adless 
individual  receivers.  Data  Link  is  oqsected  to  reduce  frequency  congestion  on  existing  voice 
radio  communication  channels.  It  will  also  enhance  the  safety  and  productivity  of  ATC 
operations. 

In  order  to  insure  that  the  introduction  of  Data  Link  will  result  in  the  greatest  possible 
benefit,  the  FAA  Technical  Center  is  conducting  a  program  of  research  and  development 
to:  (a)  guide  the  design  of  effective  ATC  services;  (b)  evaluate  their  impact  on  system 
performance;  and  (c)  promote  optimal  integration  between  the  system  and  its  air  traffic 
controller  and  aircrew  users. 

Original  developmental  work  focused  on  designing  and  testing  a  group  of  initial  services 
and  functions  for  the  currently  operational  en  route  Host  computer/Plan  View  Display 
(PVD)  workstation  system.  Controller-in-the-loop  simulation  studies  were  used  to  prepuce 
refined  PVD  displays,  command  inputs,  and  communications  procedures  which  were  used 
as  the  basis  for  preparing  a  functional  specification  for  Data  Link  service  implementation  in 
the  Host  computer  system.  The  initial  services  defined  within  the  specification  include 
altitude  assignment,  transfer  of  communication,  menu  text  functions,  communication 
backup,  and  initial  contact. 

As  part  of  the  Advanced  Automation  System  (AAS)  program,  a  new  controller  workstation 
will  begin  to  replace  the  PVD  controller  interface  over  the  next  several  years.  This  Initial 
Sector  Suite  System  (ISSS)  common  console  will  introduce  color  coding  dimensions,  non- 
dedicated  display  surfaces,  logical  displays,  key^ard  inputs,  and  a  new  command  language 
syntax.  Because  of  these  changes,  empirical  research  will  be  needed  to  produce  a  Data 
Link  implementation  specification  which  will  optimize  controller  usability  by  conforming  to 
general  Data  Link  design  principles,  while  being  fully  integrated  with  the  conventions  for 
user  interaction  unique  to  the  ISSS  design.  The  overall  goal  of  the  study  described  in  this 
report  was  to  obtain  initial  controller  input  to  the  development  of  effective  ISSS  Data  Link 
service  designs. 

The  primary  objective  of  this  study  was  to  evaluate  the  controller  interface  and  procedures 
associated  with  candidate  designs  for  initial  ISSS  Data  Link  services  and  functions.  The 
study  also  was  used  as  an  opportunity  to  address  two  secondary  objectives.  Evaluations  of 
system  fidelity  were  obtained  to  assess  the  capability  of  a  prototype  ISSS  simulator  to 
support  future  development  and  testing  of  Data  Link  services.  In  addition,  test  runs  were 
conducted  to  obtain  preliminary  estimates  of  the  projected  impact  of  ISSS  Data  Link  on 
controller  capabilities  and  ATC  system  performance. 

Eight  controllers  engaged  in  a  series  of  training  exercises,  structured  design  reviews,  full 
scale  simulation  tests,  and  formal  debriefings  to  provide  evaluative  data.  Data  Link  training 
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and  full  scale  simulation  testing  were  performed  in  the  Host/PVD  laboratory  and  in  a 
prototype  ISSS  simulation  facility  in  order  to  provide  a  comparative  baseline  for  evaluation 
of  the  candidate  ISSS  Data  Link  designs.  Identical  test  scenarios  were  presented  in  both 
simulation  environments  and  were  derived  from  the  Oakland  Air  Route  Traffic  Control 
Center  (ARTCC). 

The  design  review  process  revealed  a  number  of  deficiencies  in  the  candidate  versions  of 
the  initial  ISSS  Data  Link  ATC  service  designs,  and  generated  design  changes  to  remediate 
those  deficiencies.  Requirements  for  modifications  and  enhancements  to  the  candidate 
service  designs  included;  (1)  the  development  of  speed  and  heading  services;  (2)  the 
addition  of  logic  checks  to  prevent  inadvertent  deletion  of  open  Data  Link  transactions;  (3) 
modification  of  the  initial  contact  service  to  prevent  a  high  incidence  of  false  alarm  alerts; 
and  (4)  the  development  of  a  capability  to  display  a  historical  record  of  Data  Link 
transactions  that  have  been  successfully  completed  with  an  aircraft.  In  addition,  the  results 
indicated  that,  to  facilitate  Data  Link  integration,  recommendations  should  be  forwarded  to 
the  AAS  program  to  modify  current  command  input  specifications. 

The  i>articipating  controllers  favorably  evaluated  the  ISSS  prototype  simulation  system  as  a 
test  bed  for  continued  Data  Link  service  development.  Suggested  improvements  included 
the  addition  of  a  limited  number  of  additional  ISSS  views  and  command  functions, 
enhancement  of  the  simulated  aircraft  models,  and  the  expansion  of  the  system  to  multiple 
common  console  suites. 

The  finding;^  derived  from  the  full  scale  simulation  phase  of  the  study  demonstrated  that 
Data  Link  significantly  reduced  occupancy  of  the  voice  radio  channel  by  controllers,  and 
that  this  benefit  was  achieved  with  no  adverse  impact  on  controller  workload.  Furthermore, 
the  results  indicated  that  Data  Link  will  increase  system  safety,  and  that  the  combination  of 
ISSS  and  Data  Link  will  produce  a  significantly  greater  positive  effect  on  controller 
e^iciency  and  productivity  than  the  implementation  of  either  system  alone. 

It  was  concluded  that  two  way  Data  Link  services  are  fully  compatible  with  the  ISSS.  The 
results  suggest  that  Data  Link  will  enhance  the  efficiency  of  domestic  ATC  operations  by 
e}q}andihg  the  capacity  of  the  air-ground  communications  channel.  They  also  indicate  that 
this  positive  effect  will  be  enhanced  by  the  improved  controller  interface  associated  with  the 
ISSS. 

Based  on  the  results  and  conclusions  outlined  above,  as  well  as  others  described  in  this 
report,  it  is  recommended  that  the  FAA  continue  development  of  Data  Link  ATC  services 
for  the  ISSS,  and  that  it  should  integrate  these  services  with  the  ISSS  implementation 
schedule  at  the  earliest  feasible  opportunity.  Future  work  with  the  ISSS  should  include  the 
modification  of  the  Data  Link  services  as  su^ested  by  the  study  findings,  testing  with 
multiple  console  suites  at  each  sector,  and  evaluation  of  Data  Link  communications 
functions  to  be  performed  by  associate  controllers. 
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This  document  presents  the  results  of  a  Federal  Aviation  Administration  (FAA)  Technical  Center 
investigation  of  en  route  air  traffic  control  (ATC)  services  developed  for  transmission  using  Data 
Link  technology.  Candidate  designs  for  five  ATC  services  and  functions  for  the  new  Initial  Sector 
Suite  System  (ISSS)  common  console  were  prepared  based  upon  design  specifications  originally 
developed  for  the  currently  operational  Host  computer/Plan  View  Display  (PVD)  system,  and 
upon  specifications  for  the  ISSS  controller  interface.  The  designs  were  implemented  on  a 
prototype  ISSS  simulation  system  for  review  and  evaluation  by  air  traffic  controUers. 

Subject  controllers  participated  in  simulated  en  route  airspace  test  trials  to  reconunend 
requirements  for  user  interface  and  procedural  design  changes  and  enhancements,  and  to  provide 
projective  assessments  regarding  the  impact  of  ISSS  Data  Link  on  controller  capabilities  and  ATC 
system  performance.  The  study  was  the  fi  st  in  a  planned  series  of  iterative  design  development 
tests  which  will  culminate  in  the  production  of  functional  design  specifications  for  an  operational 
en  route  ATC  Data  Link  communications  system  supported  by  the  ISSS. 


Maintenance  of  the  safe  and  efficient  flow  of  air  traffic  is  predicated  on  the  availability  of  a  two- 
way  communications  link  between  ATC  facilities  and  aircraft  systems.  For  the  past  50  years,  the 
air-ground  link  has  been  provided  by  simplex  radio  charuiels  over  which  air  traffic  controllers  and 
aircrew  exchange  voice  messages.  The  voice  radio  medium  has  proven  its  effectiveness. 
However,  current  growth  in  the  volume  of  air  traffic  and  increasing  air-ground  information 
transfer  requirements  are  beginning  to  exceed  its  inherently  limited  capacity.  As  a  result,  the 
communications  system  has  begun  to  place  significant  constraints  on  the  overall  performance  of 
the  ATC  system. 

Because  the  voice  radio  link  operates  in  a  broadcast  mode  between  a  single  control  position  and 
all  aircraft  operating  in  the  airspace  sector,  frequency  congestion  is  a  common  occurrence  when 
the  volume  and  complexity  of  air  traffic  increases.  Such  saturation  of  the  communications 
channel  affects  the  performance  of  the  ATC  system  by  preventing  the  timely  issuance  of 
clearances,  and  by  restricting  the  vital  exchange  of  information  upon  which  safe  and  efficient 
operation  of  the  National  Airspace  System  (NAS)  depends. 

In  addition  to  the  limitations  that  it  imposes  through  frequency  congestion,  the  voice  radio 
channel  has  been  identified  as  a  major  contributor  to  errors  in  the  ATC  system.  The  FAA  has 
noted  that  as  many  as  23  percent  of  all  operational  errors  are  caused  either  directly  or  indirectly 
by  communications  mistakes  (New  York  Times.  1988).  Similarly,  compilations  of  voluntary 
reports  provided  to  the  Aviation  Safety  Reporting  System  by  pilots  and  controllers  have  shown 


that  a  majority  of  all  potentially  hazardous  incidents  that  are  filed  implicate  ineffective  verbal 
information  transfer  (Billings  and  Reynard,  1981). 

Investigations  of  the  nature  of  prevalent  communications  errors  demonstrate  that  they  are 
typically  the  result  of  an  interaction  between  the  characteristics  of  the  voice  radio  system  and  the 
inherent  perceptual  and  cognitive  characteristics  of  its  human  users  (Shingledecker,  1990). 
Acoustic  confusions,  alphanumeric  transpositions,  misinterpretation  due  to  pronunciation  and 
phraseology  problems,  poor  memory  for  transient  speech  presentations  of  ATC  information,  and 
blocking  of  the  radio  channel  caused  by  improper  keying  techniques  are  common  sources  of 
human-induced  error  found  by  these  studies.  In  addition,  many  errors  seem  to  be  potentiated  by 
the  frequency  congestion  problem  as  users  experience  difficulty  in  monitoring  for  relevant 
messages  on  the  crowded  radio  channel,  and  become  reluctant  to  clarify  suspected  confusions  to 
avoid  further  congestion. 

1 .2.2  Data  Link  Communications. 

Data  Link  is  a  digital  communications  technology  which  is  being  developed  as  a  supplement  to 
traditional  voice  radio  for  two-way,  air-ground  ATC  communications  and  other  applications.  As 
shown  in  figure  1,  Data  Link  communications  can  be  supported  by  several  transmission  media. 
These  include  very  high  frequency  (VHP)  radio,  satellite  links,  and  the  Mode  Select  (Mode  S) 
secondary  surveillance  radar  system.  Under  current  FAA  plans,  these  multiple  links  will  be 
integrated  within  a  common  Aeronautical  Telecommunications  Network  to  provide  seamless  air- 
ground  communications  throughout  the  NAS. 

Regardless  of  the  specific  method  used  to  create  the  channel.  Data  Link  communications  are 
distinguished  from  traditional  voice  radio  links  in  two  essential  ways.  First,  unlike  analogue  voice 
messages.  Data  Link  messages  consist  of  digitally  coded  information.  Thus,  data  may  be  entered 
for  transmission  either  manually,  or  by  direct  access  to  information  contained  in  airborne  or 
ground-based  computers.  Furthermore,  the  capability  of  a  digital  system  to  provide  automatic 
error  checking  of  sent  and  received  messages  makes  Data  Link  a  highly  reliable  system  which  is 
not  susceptible  to  degradation  by  interfering  noise  sources. 

The  second  way  in  which  Data  Link  differs  from  the  voice  radio  channel  is  its  c^ability  to 
discretely  address  individual  receivers.  Unlike  the  simplex  radio  system  which  permits  only  a 
single  speaker  to  transmit  on  the  broadcast  frequency  ai  any  time.  Data  Link  messages  can  be  sent 
selectively.  Furthermore,  transmission  rates  are  not  artificially  bounded  by  the  effective  speaking 
and  listening  rates  of  the  user.  As  a  result.  Data  Link  channels  can  have  a  much  higher  capacity 
than  voice  channels,  and  critical  messages  sent  by  a  controller  are  assured  of  receipt  only  by  the 
intended  aircraft. 
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FIGURE  1.  PROPOSED  DATA  LINK  SYSTEM 
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1.2.3  ATC  Applications  of  Data  Link. 

The  development  of  Data  Link  communications  is  a  critical  element  of  the  FAA's  Capital 
Investment  Plan  (CIP)  to  update  and  enhance  ATC  technology.  In  its  later  phases,  the  CIP  will 
introduce  sophisticated  automation  systems  that  will  make  use  of  intelligent  software  and 
numerous  data  sources  to  optimize  the  flow  of  traffic.  These  advanced  systems  will  be  capable  of 
optimizing  traffic  flow,  detecting  and  resolving  potential  flight  path  conflicts,  providing  pilots  with 
preferred  routings,  and  preventing  disruptions  to  overall  system  operations.  A  majority  of  the 
plaimed  automation  innovations  will  depend  upon  the  reliable,  high  capacity  exchange  of 
information  between  airborne  and  ATC  computers  that  will  be  provided  by  the  Data  Link  system. 

Even  before  it  fulfills  its  function  of  enabling  end-state  system  automation.  Data  Link  will  provide 
air  traffic  controllers  and  aircrew  with  a  new  channel  of  direct  communication  which  has  the 
potential  to  produce  significant  improvements  in  system  safety  and  productivity.  In  this  role,  the 
unique  characteristics  of  Data  Link  communications  are  expected  to  relieve  constraints  on 
efficiency  that  ate  attributable  to  congestion  on  voice  radio  frequencies.  It  will  also  reduce 
prevalent  communication  errors  which  produce  disruptive  delays  and  can  compromise  flight 
safety. 

Demands  on  the  voice  channel  should  be  reduced  in  proportion  to  the  number  of  ATC  services 
that  are  assigned  to  the  Data  Link  system.  In  addition,  by  automating  or  simplifying  pilot  and 
controller  functions  in  the  communication  process  that  are  subject  to  error.  Data  Link  should 
improve  the  overall  effectiveness  of  information  transfer.  For  example,  using  Data  Link  it  will  be 
possible  to  reduce  ambiguous  message  transmissions  by  storing  standard  clearances  in  computer 
memory  for  simplified  uplink  to  an  aircraft.  Likewise,  failures  to  detect  messages  and  accidental 
acceptance  of  clearances  by  unintended  aircraft  will  be  eliminated  by  discrete  addressing. 
Interpretation  errors  should  be  reduced  by  the  availability  of  a  persistent  and  recallable  visual 
display  of  the  received  data.  Finally,  the  system  will  have  the  ability  to  automatically  verify  the 
integrity  of  a  message  without  human  intervention. 

1.2.4  En  Route  Data  Link  Controller  Research  and  Development  at  the  FAA  Technical  Center. 

As  discussed  above,  the  comparative  technical  advantages  of  Data  Link,  and  its  ability  to  supply  a 
second  air-ground  communication  channel,  make  it  a  promising  candidate  for  enhancing  overall 
ATC  system  performance.  However,  Data  Link  also  will  introduce  a  profound  change  in  the  way 
tasks  are  accomplished  by  controllers,  and  in  the  way  aircrew  will  receive  and  respond  to  ATC 
instructions.  Because  of  this,  the  ultimate  success  of  Data  Link  will  be  critically  dependent  on  the 
extent  to  which  it  is  thoroughly  integrated  with  its  human  users  and  with  the  full  range  of  tasks 
that  they  are  required  to  perform. 

Recognition  of  the  need  to  consider  operational  suitability  and  human  factors  issues  as  primary 
drivers  of  the  design  process  prompted  the  FAA  Technical  Center  to  initiate  a  program  of  manned 
simulation  research  to  guide  the  development  of  Data  Link  ATC  services.  The  overall  goals  of 
this  research  are  to  ( 1)  define  useful  Data  Link  services,  (2)  determine  the  user  information 
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requirements  for  Data  Link  communications,  (3)  develop  display  formats,  data  entry  methods  and 
procedures  which  promote  efficient  controller  performance,  and  (4)  evaluate  the  impact  of  Data 
Link  services  on  both  human  and  system  performance. 

The  design  of  Data  Link  ATC  services  began  in  1988  at  the  FAA  Technical  Center  with  a  series 
of  controller-in-the-loop  simulation  studies.  These  studies  were  aimed  at  iteratively  developing 
and  testing  a  group  of  initial  services  and  functions  for  the  currently  operational  NAS  en  route 
Host  computer/PVD  workstation  system.  Based  upon  measures  of  controller  workload, 
performance,  and  operational  suitability,  design  development  studies  produced  refined  PVD 
displays,  command  inputs,  and  communications  procedures.  These  were  used  as  the  basis  for 
preparing  a  functional  specification  for  Data  Link  service  implementation  in  the  Host  computer 
system  (Buck  et.  al.,  1991). 

The  initial  services  defined  within  the  specification  include  altitude  assignment,  transfer  of 
communication,  menu  text  functions,  and  communication  backup.  Host/PVD  research  conducted 
subsequent  to  the  publication  of  the  initial  specification  also  produced  a  capability  to  receive  an 
initial  contact  message  from  Data  Link-equipped  aircraft  following  the  transfer  of  communication. 

1.3  DATA  LINK  FOR  I$S$. 

As  part  of  the  Advanced  Automation  System  (AAS)  program,  a  new  controller  workstation  will 
be  introduced  into  the  en  route  ATC  environment  within  the  next  few  years.  With  the  evolution 
of  the  AAS,  this  ISSS  common  console  will  eventually  replace  all  Host/PVD  controller  interfaces. 
During  the  first  phase  of  the  transition  process,  the  conunon  console  will  be  supported  by  the 
same  Host  computer  that  supports  the  current  PVD  workstation  and  will,  as  a  minimal 
requirement,  provide  functional  capabilities  that  are  equivalent  to  the  existing  system. 

This  shared  functionality  and  computer  support  for  the  common  console  and  PVD  are  expected  to 
make  many  of  the  design  specifications  that  were  developed  from  PVD  research  findings  directly 
applicable  to  the  implementation  of  initial  Data  Link  services  for  the  ISSS.  However,  the  ISSS 
will  introduce  new  display  color  coding  dimensions,  non-dedicated  display  surfaces,  logical 
displays,  keyboard  inputs,  and  a  new  command  language  syntax.  These  changes  would 
accommodate  a  number  of  candidate  implementations  under  the  general  design  specification. 

Thus,  additional  empirical  research  will  be  needed  to  develop  an  implementation  specification  for 
the  ISSS  that  will  insure  optimal  controller  usability.  Such  a  specification  must  embody  the 
general  Data  Link  human  factors  design  priniciples  discovered  in  earlier  research,  while  being  fully 
integrated  with  the  conventions  for  user  interaction  unique  to  the  ISSS.  The  primary  purpose  of 
the  study  described  in  this  report  was  to  obtain  initial  controller  input  to  the  development  of 
effective  ISSS  Data  Link  service  designs. 

1 .4  INITIAL  EN  ROUTE  ISSS  DATA  LINK  SERVICES. 


In  order  to  provide  a  baseline  for  the  development  of  ISSS  Data  Link,  the  FAA  generated  a  set  of 
candidate  designs  for  an  initial  set  of  ATC  services  and  functions.  These  designs  for  controller 


displays,  command  inputs  and  ATC  computer  automation  functions  were  based  on  requirements 
originally  developed  for  the  Host/PVD  system,  and  on  controller  interface  and  interaction 
specifications  published  for  the  ISSS. 

Detailed  descriptions  of  the  baseline  candidate  designs  that  were  evaluated  in  this  study  are 
presented  in  appendix  A.  The  general  functions  performed  by  the  services,  and  brief  descriptions 
of  how  they  are  provided  using  Data  Link,  are  presented  below: 

a.  Transfer  of  Communication  (TOC).  TOC  is  the  message  sent  to  an  aircraft  after  track 
control  has  been  passed  to  a  new  sector  instructing  the  pilot  to  change  radio  frequencies.  Using 
the  candidate  Data  Link  service,  this  message  is  automatically  prepared  b^  \TC  computer  and 
uplinked  to  the  pilot  either  automatically  when  track  control  is  accepted,  a  a  controller 
input  action. 

b.  Initial  Contact  (IC).  When  an  aircraft  receives  a  new  radio  frequency,  current  ATC 
procedures  require  the  pilot  to  contact  the  new  controller  and,  in  many  cases,  to  report  the 
aircraft's  currently  assigned  altitude.  With  the  candidate  Data  Link  version  of  IC  tested  in  this 
study,  the  aircraft  (pilot  or  airborne  automation)  appends  its  assigned  altitude  to  th  wilco 
response  for  the  TOC  message.  Upon  receipt,  the  altitude  is  automatically  compared  to  the 
assigned  altitude  in  the  NAS  data  base.  An  alert  is  presented  to  the  receiving  controller  if  the 
aircraft  fails  to  downlink  the  altitude,  or  if  the  downlinked  altitude  and  data  base  altitude  do  not 
match. 

c.  Altitude  Assignment  (AA).  Using  the  candidate  ISSS  Data  Link  design,  the  controller  can 
uplink  an  assigned  altitude  or  an  interim  altitude  through  keyboard  command  actions  specifying 
the  intended  aircraft  (one  or  more)  aiKl  the  altitude  value.  Receipt  of  the  pilot  wilco  automatically 
updates  the  appropriate  Full  Data  Block  (FDB)  on  the  controller's  situation  display  and,  for 
assigned  altitudes,  the  NAS  data  base. 

d.  Menu  Text  (MT).  MT  is  a  Data  Link  function  which  permits  the  controller  to  select  and 
uplink'a  commonly  used  message  from  a  menu  view.  In  the  present  study,  the  menu  contained 
altitude,  speed  and  heading  clearances  as  well  as  non-control  text  messages. 

e.  Communications  Backup  (CB)  (Free  Text).  CB  provides  the  controller  with  an  ability  to 
compose  and  uplink  an  unformatted  (free  text)  message  using  keyboard  inputs. 

The  candidate  services  were  designed  using  accepted  ISSS  display  and  command  conventions. 
The  MT  menu  and  the  Data  Link  Status  List,  used  to  provide  information  on  the  content  of  open 
transactions  and  their  status  were  implemented  as  ISSS  views  (logical  displays).  Data  Link  inputs 
conformed  to  the  ISSS  command  syntax,  and  were  displayed  in  the  ISSS  Message  Composition 
(MC)  view.  Symbology  was  added  to  the  first  line  of  the  FDB  to  provide  a  Data  Link  equipage 
and  eligibility  indicator,  and  additional  FDB  modifications  were  made  to  provide  message  status, 
content  and  alert  displays  for  some  of  the  services. 
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The  following  sections  of  this  report  present  the  research  methodology  that  was  used  and  the 
findings  that  were  obtained  in  the  first  FAA  Technical  Center  controller  evaluation  of  en  route 
Data  Link  ATC  services  for  the  ISSS.  Section  2  describes  the  specific  objectives  of  the  study  and 
the  testing  approach  that  was  used  to  achieve  these  objectives.  Section  3  presents  the  results  of 
the  testing.  Sections  4  and  5  list  the  conclusions  that  were  derived  from  the  results  and  offer 
reconunendations  for  future  development  of  an  operational  ISSS  Data  Link  capability. 

2 . lESTDESCElPTIQlS- 

2.1  .QBigcnyEs. 

This  study  was  conducted  to  achieve  the  following  primary  objectives,  in  pursuit  of  the  goal  to 
develop  initial  Data  Link  services  and  procedures  for  the  ISSS: 

a.  Evaluate  the  usability  and  operational  suitability  of  the  controller  interface,  and  procedures 
associated  with  candidate  designs  for  initial  ISSS  Data  Link  services  and  functions. 

b.  Provide  design  guidance  for  correcting  any  detected  problems  with  the  candidate  controller 
interface,  and  for  enhancing  the  services. 

c.  Evaluate  the  capability  of  a  prototype  ISSS  simulation  system  to  support  future 
development  and  testing  of  Data  Link  services. 

d.  Obtain  preliminary  estimates  of  the  projected  impact  of  ISSS  Data  Link  on  controller 
capabilities  and  ATC  system  performance. 

2.2  TEST  APPROACH. 

Unique  expertise  in  the  design  of  en  route  Data  Link  ATC  services  and  in  the  operation  of  the 
ISSS  resides  in  two  separate  teams  of  air  traffic  controllers.  The  teams  have  been  appointed  by 
the  FAA  to  represent  operational  concerns  in  the  development  of  these  new  ATC  systems. 
Members  of  the  En  Route  Systems  Team  (ERST)  have  been  actively  involved  in  the  evolution  of 
the  common  console  hardware,  display  requirements  and  ISSS  procedures.  Beyond  acting  as 
overseers  of  this  effort,  these  team  members  have  the  highest  available  level  of  controller 
familiarity  with  ISSS  design  conventions,  common  console  operation,  and  procedural  concepts  for 
the  future  ISSS-based  en  route  ATC  environment. 

Members  of  the  Air  Traffic  Data  Link  Validation  Team  (ATDLVT)  directly  participated  in  the 
design  of  the  initial  en  route  Data  Link  services  for  the  Host/PVD,  and  were  closely  involved  with 
the  evaluation  exercises  conducted  in  the  Data  Link  test  bed.  Thus,  these  controllers  are 
thoroughly  versed  in  the  design  philosophy  underlying  Data  Link  ATC  services,  as  well  as  the  use 
of  the  system  under  various  simulated  air  traffic  scenarios. 
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The  present  study  drew  upon  the  expertise  from  these  two  teams,  as  well  as  the  members'  shared 
operational  experience  in  en  route  ATC  by  recruiting  members  from  both  teams  to  participate  in 
the  evaluation  of  the  candidate  ISSS  Data  Link  implementation.  These  controllers  engaged  in  a 
series  of  training  exercises,  structured  design  reviews,  full  scale  simulation  tests,  and  formal 
debriefings  to  provide  evaluative  data.  Data  Link  training  and  full  scale  simulation  were 
performed  both  in  the  Host/PVD  laboratory  and  in  the  prototype  simulation  facility  to  provide  a 
comparative  baseline  for  evaluation  of  the  candidate  ISSS  Data  Link  designs.  Identical  test 
scenarios  were  presented  in  both  simulation  environments,  and  were  derived  from  the  Oakland  Air 
Route  Traffic  Control  Center  (ARTCC)  using  four  airspace  sectors  with  arrival  and  departure 
traffic  from  the  San  Francisco  International  Airport  (SFO). 

To  ensure  that  controller  evaluations  were  based  on  accurate  knowledge  of  the  current  Host/PVD 
Data  Link  and  ISSS  designs,  the  first  phase  of  this  study  was  devoted  to  classroom  training  and 
practice.  This  included  instruction  on  the  PVD  Data  Link  service  designs,  the  ISSS  candidate 
Data  Link  service  designs,  and  general  operation  of  the  ISSS  common  console. 

In  the  second  phase  of  the  study,  all  of  the  subject  controllers  participated  in  a  systematic 
evaluation  of  the  candidate  ISSS  service  designs.  For  each  candidate  service,  this  design  review 
activity  required  the  controllers  to  examine  precise  descriptions  of  inputs  and  displays,  perform 
correlated  design  test  exercises  in  the  prototype  ISSS  simulator,  and  complete  a  detailed 
evaluation  booklet. 

In  the  final  phase  of  the  study,  the  controllers  participated  in  full  scale  simulation  exercises.  These  test 
runs  were  conducted  to  provide  the  experience  needed  to  assess  the  overall  effectiveness  and 
acceptability  of  the  candidate  ISSS  Data  Link  designs.  They  also  presented  a  basis  for  making 
projective  judgments  regarding  the  impact  of  Data  Link  under  an  actual  operational  implementation. 

2.3  TEST  CONDUCT. 

2.3.1  Subjects. 

The  subjects  for  this  study  were  eight  Full  Performance  Level  (FPL)  ATC  specialists  who  were 
proficient  in  ARTCC  radar  control  operations.  Six  of  these  controllers  were  recruited  from  the 
ATDLVT  and  had  participated  in  the  conceptual  development  and  testing  of  Data  Link  services  for 
the  Host/PVD  system.  The  remaining  two  subjects  were  recruited  from  the  ERST.  Both  had 
participated  in  ISSS  controller  interface  reviews  on  that  team,  and  on  the  earlier  Sector  Suite 
Requirements  Validation  Team  (SSRVT)  during  original  ISSS  design  deliberations. 

2.3.2  Test  Facilities.  Test  Scenarios,  and  Data  Link  Transaction  Times. 

The  study  was  conducted  in  two  laboratories  located  at  the  FAA  Technical  Center.  Training  and 
testing  on  the  Host/PVD  Data  Link  services  were  performed  in  the  en  route  portion  of  the  Data  Link 
test  bed.  Pseudopilots  operating  the  dynamic  simulation  (DYSIM)  function  controlled  aircraft  targets, 
and  conducted  air-ground  voice  and  data  communications  with  the  subject  controllers.  The  Host^VD 
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simulation  system  in  the  Data  Link  test  bed  provided  all  current  NAS  en  route  functions  and  displays, 
and  supported  all  initial  Data  Link  services  developed  for  that  system  in  earlier  studies. 

Training  and  testing  on  the  ISSS  common  console  were  conducted  using  the  ISSS  prototype 
simulation  facility  and  associated  pseudopilot  capabilities.  The  ISSS  prototype  is  an  ATC  simulator 
which  includes  four  common  console  replicas.  The  replicas  use  actual  ISSS  keyboards,  trackballs, 
cathode  ray  tube  color  displays.  The  prototype  software,  as  implemented  for  this  study,  supported 
primary  command  inputs  and  logical  displays  specified  in  ISSS  specification  documents,  as  well  as 
candidate  versions  of  ISSS  initial  Data  Link  services.  In  addition,  the  software  provided  the  ability  to 
dynamically  simulate  prepared  air  traffic  scenarios,  and  to  alter  aircraft  movement  in  response  to 
pseudopilot  inputs. 

Four  sectors  of  adjacent  en  route  airspace  were  simulated  on  the  Host/PVD  and  ISSS  prototype 
systems.  Scenarios  developed  for  both  systems  used  the  Oakland  ARTCC  adaptation  and  identical 
airspace  sectors.  The  Oakland  ARTCC  adaptation  was  chosen  for  this  study  to  permit  later  addition 
of  the  Bay  Terminal  Radar  Approach  Control  (TRACON)  and  Oakland  Oceanic  operations.  Future 
simulation  studies  using  this  expanded  configuration  will  examine  Data  Link  functionality  in  multiple 
ATC  environments. 

Hgure  2  presents  a  simplified  map  of  the  test  air^ace,  along  with  the  primary  arrival  and  departure 
traffic  flows  in  the  four  sectors.  Traffic  patterns  used  in  the  scenarios  were  extracted  from  Oakland 
ARTCC  System  Analysis  and  Recording  (SAR)  tapes.  Traffic  percentage  volumes  were  based  on 
actual  Oakland  ARTCC  Operationally  Acceptable  Level  of  Traffic  (OALT)  values  taken  from  the 
Traffic  Management  System  data  base.  All  of  the  sectors  worked  both  arriving  and  departing  aircraft 
from  the  SFO,  along  with  a  small  number  of  overflights.  The  majority  of  the  traffic  was  con^sed  of 
air  carrier  jets,  with  a  smaller  number  of  turbo  props  and  military  aircraft. 

The  subjects  controlled  aircraft  in  accordance  with  the  provided  interfacility  Letter  of  Agreement 
(LOA)  and  Sector  Standard  Operating  Procedures  (SOPS).  All  arrival  aircraft  were  required  to  meet 
specific  in-trail  altitude,  speed  and  routing  restrictions  prior  to  the  hand-off  to  Bay  TRACON.  All 
departure  traffic  transitioned  into  Oakland  Center  airspace  on  course,  climbing  to  altitudes  specified  in 
the  LOA. 

Several  changes  to  the  actual  airspace  were  made  to  reduce  airspace  training  requirements  for  this 
study.  The  airspace  was  modified  to  remove  shelved  portions  of  some  sectors  so  that  sectors  41, 24 
and  12  controlled  airspace  from  the  surface  to  FL230,  exclusive  of  Bay  TRACON  airspace  14,000  feet 
and  below.  Sector  35  owned  all  airspace  from  the  surface  up.  In  addition,  unnecessary  intersections, 
airways,  jet  routes,  navigation  aids,  and  unused  airports  were  removed  from  the  maps  to  further 
simplify  the  problem.  Finally,  the  LOA  and  SOPS  were  rewritten  to  allow  operation  of  the  sectors 
with  minimal  coordination.  This  change  permitted  the  single  radar  controller  position,  provided  by  the 
simulation  facilities,  to  operate  the  sector  without  assistance  from  a  Data  (manual)  controller. 
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A  common  distribution  of  total  transaction  times  was  enforced  during  all  training  and  test  simulation 
trials  in  which  Data  Link  communications  were  employed.  Total  transaction  time  was  defined  as  the 
time  interval  beginning  with  the  controller's  data  entry  initiating  an  uplink  and  ending  with  the  receipt 
of  a  pilot  response.  These  were  randomly  drawn  horn  a  rectangular  distribution  representing  nominal 
uplink  and  downlink  transmission  times,  plus  a  pilot  response  delay.  The  mean  of  the  distribution  was 
18  seconds  with  a  range  of  12  to  24  seconds. 

2.3.3  Test  Procedures  and  Data  Collection. 

Z.3J.L  Trainiog- 

One  week  prior  to  the  study,  all  subjects  received  an  airspace  training  package  (appendix  B),  along 
with  a  brief  description  of  the  study  goals  and  methodology.  The  subjects  were  asked  to  study  the 
airspace  before  arriving  at  the  FAA  Technical  Center. 

Upon  arrival,  each  of  the  eight  subjects  was  assigned  to  one  of  the  four  sectors  in  the  Oakland 
ARTCC,  with  two  subjects  per  position.  In  order  to  maximize  airspace  familiarity  and  focus  on  Data 
Link  operations,  these  assignments  were  maintained  for  all  training  and  subsequent  testing. 

Preparations  for  data  collection  began  by  providing  all  subjects  with  instruction  and  training  on  the 
general  operation  of  the  prototype  ISSS  common  console,  and  on  the  Host/PVD  and  ISSS 
implementations  of  the  initial  Data  Link  services.  Formal  training  was  conducted  over  a  period  of  3 
days  in  three  stages. 

In  the  first  stage,  the  subjects  received  a  1-hour  briefing  on  the  Oakland  ARTCC  airspace,  followed  by 
a  1-hour  classroom  session  explaining  and  illustrating  all  Host/PVD  Data  Link  command  inputs, 
displays,  and  procedures.  This  was  followed  by  4  hours  of  hands-on  practice  in  the  Host/PVD  Data 
Link  test  bed.  During  this  laboratory  session,  the  two  subjects  assigned  to  each  PVD  practiced  Data 
Link  operation  in  scenarios  which  increased  in  traffic  volume  from  50  to  75  percent  of  airspace 
capacity  after  approximately  2  hours.  All  aircraft  in  the  scenario  were  Data  Link  equipped  to 
maximize  training  efficiency.  The  paired  subjects  alternated  between  observing  and  actively 
controlling  traffic.  The  practice  session  was  followed  by  a  30-  minute  group  session  to  address 
Host/PVD  Data  Link  and  airspace  questions. 

The  second  stage  of  training  introduced  the  subjects  to  general  operation  of  the  ISSS  common 
console.  This  training  began  with  1  hour  of  classroom  instruction  on  the  ISSS  conunand  language  and 
syntax,  logical  displays,  and  keyboard  layout.  ISSS  functions  not  supported  by  the  prototype  were 
identified.  The  candidate  Data  Link  services  were  not  introduced  during  this  briefing.  Classroom 
instruction  was  followed  by  a  4-hour  practice  session  in  the  ISSS  simulation  facility.  Air  traffic 
scenarios,  with  volumes  increasing  from  50  to  75  percent  of  airspace  capacity  and  approximately 
identical  to  those  used  in  the  Host/PVD  training,  were  presented  to  permit  the  subjects  to  exercise  the 
ISSS  functions.  During  this  stage  of  training,  all  communications  were  conducted  using  voice  radio. 
Subjects  worked  in  pairs,  alternating  as  described  in  the  Host/PVD  training  protocol.  The  practice 
session  was  followed  by  a  30-minute  question  and  answer  period. 
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The  final  stage  of  training  provided  subjects  with  instruction  on  the  candidate  initial  Data  Link  services 
developed  for  the  ISSS  common  console.  A  1-hour  classroom  session  was  used  to  brief  the  subjects 
on  Data  Link  inputs  and  displays,  followed  by  4  hours  of  practice  in  the  ISSS  prototype  facility.  The 
hands-on  training  followed  the  same  protocol  as  that  used  in  the  first  two  training  stages  and  used 
identical  airspace  scenarios.  All  aircraft  were  Data  Link  equipped. 

2. 3. 3. 2  PtQtQtypg  Evaluatipn. 

After  the  subjects  had  finished  ISSS  training,  they  completed  a  questionnaire  and  participated  in  a 
debriefing  designed  to  provide  an  assessment  of  the  quality  of  simulation  provided  by  the  ISSS 
prototype  system.  While  the  subjects  differed  greatly  in  their  prior  experience  with  actual  ISSS 
hardware  and  operations,  they  were  all  asked  to  evaluate  the  overall  fidelity  of  simulation  provided  by 
the  system,  the  operational  realism  of  the  system's  performance,  and  the  degree  to  which  the  prototype 
emulated  the  "look  and  feel"  of  the  actual  ISSS  common  console.  The  controllers  were  asked  to  judge 
these  qualities  in  relation  to  simulation  requirements  for  developing  and  testing  Data  Link  functions, 
rather  than  against  an  absolute  criterion  of  perfect  ISSS  emulation.  Debriefing  discussions  centered  on 
identifying  needed  improvements  to  the  ISSS  prototype  simulation  system  for  future  Data  Link 
studies.  A{^ndix  C  includes  a  copy  of  the  questionnaire  used  in  the  prototype  evaluation. 

2.3.3.3  ISSS  Data  Link  Design  Review. 

Evaluation  of  ISSS  Data  Link  began  on  the  fourth  day  of  the  study  with  a  formal,  structured  review  of 
the  candidate  ISSS  service  designs.  The  eight  subjects  completed  the  design  review  while  seated  in 
two-controller  teams  at  the  prototype  common  console  workstations,  and  controlling  aircraft  in  a 
series  of  brief  scripted  scenarios.  Each  of  these  scenarios  or  frames  was  designed  to  permit  the 
controllers  to  exercise  one  of  the  initial  candidate  service  designs,  or  a  group  of  related  design  features 
conunon  to  all  the  services. 

Evaluations  were  made  by  completing  sections  of  a  design  review  questionnaire  booklet  which  were 
correlated  with  the  individual  scenario  frames.  The  paired  subjects  worked  together  in  exercising  and 
examining  each  service  and  design  feature.  However,  they  were  instructed  to  answer  evaluation 
questions  individually. 

The  design  review  scenario  software  operated  independently  on  individual  prototype  workstations,  so 
that  the  evaluations  could  be  flexibly  paced  by  each  pair  of  controllers.  Subjects  working  at  a  console 
were  allowed  to  take  as  much  time  as  required  to  complete  each  booklet  section,  and  to  repeat  the 
associated  scenario  frame  if  necessary  before  moving  on  to  the  next  section.  In  cases  where  a  service 
would  normally  require  cooperation  with  an  adjacent  sector  (e.g.,  TOC),  the  simulation  software  was 
modified  for  the  design  review  to  emulate  these  inputs.  Test  facilitators  were  available  to  assist  the 
subjects  in  exercising  the  services,  and  to  answer  any  questions  regarding  inputs  or  displays. 

The  design  review  was  organized  into  the  following  sections:  (1)  Status  List,  Data  Block  Displays, 
and  Entry  Error  Messages;  (2)  TOC;  (3)  AA;  (4)  IC;  (5)  MT;  and  (6)  CB.  For  each  section,  the 
subjects  were  instructed  to  first  read  the  description  of  the  design  provided  in  a  separate  booklet  (see 
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appendix  A).  They  then  completed  a  scripted  set  of  activities  interacting  with  the  associated  scenario 
frame.  Finally,  they  completed  the  correlated  questionnaire  items  before  proceeding  to  the  next 
section. 


Initial  questionnaire  items  in  each  section  of  the  design  review  verified  the  fidelity  of  the  service 
implementations  by  requiring  the  subjects  to  judge  the  correspondence  between  the  descriptions  and 
their  actual  experience  with  the  ISSS  prototype.  Succeeding  items  assessed  the  acceptability  of  the 
service  implementations  observed  in  the  simulations,  and  solicited  recommendations  for  desirable  and 
required  design  modifications.  The  design  exercises  and  correlated  questionnaire  items  are  included  in 
appendix  C. 

Upon  completion  of  the  review  exercise,  all  subjects  met  with  test  personnel  for  a  group  debriefing 
session.  This  4-hour  session  was  used  to  perform  an  item-by-item  examination  of  the  subjects' 
responses  to  the  review  questionnaire.  The  emphasis  of  the  debriefing  was  to:  (1)  identify  and  resolve 
disagreements  regarding  the  fidelity  and  acceptability  of  the  service  designs  and;  (2)  achieve  a 
consensus  regarding  recommended  changes  to  the  service  designs.  Eiesignated  test  personnel 
recorded  detailed  notes  on  the  issues,  resolutions  and  design  modifications  discussed  during  the 
debriefing.  In  addition,  a  complete  audio  tape  record  was  maintained  for  future  reference  during  data 
analysis. 

2.3.3.4  Full  Scale  Simulation. 

On  the  fifth  and  sixth  days  of  the  study,  the  subjects  participated  in  a  series  of  full  scale  simulation 
tests.  The  purpose  of  these  test  runs  was  to  provide  the  subjects  with  a  realistic  simulation  experience 
as  a  basis  for  expert  comparative  evaluation  of  the  workload,  operational  utility,  and  acceptability  of 
the  ISSS  Data  Link  services,  as  implemented  for  this  study. 

During  the  full  scale  simulation  runs,  controllers  operated  in  test  scenarios  with  air  traffic  at  100 
percent  of  airspace  capacity.  They  were  required  to  control  traffic  in  the  ISSS  prototype  under  voice 
radio-only,  and  under  radio  plus  Data  Link  communication  conditions.  To  provide  a  comparative 
baseline,  the  subjects  also  were  tested  under  voice-only  and  radio  plus  Data  Link  conditions  in  the 
Host/PVD  Data  Link  test  bed.  In  Data  Link  conditions,  80  percent  of  the  aircraft  were  equipped  for 
both  Data  Link  and  voice  radio  communication,  while  the  remaining  20  percent  were  able  to 
communicate  only  via  voice  radio. 

To  minimize  the  effects  of  airspace  learning  on  controller  assessments,  two  equivalent  50-minute 
scenarios  were  used  for  these  test  runs.  These  scenarios  involved  similar  traffic  patterns  and  equal 
numbers  of  aircraft,  but  differed  slightly  in  aircraft  sequence  and  spacing. 

The  experimental  design  for  the  full  scale  simulation  testing  is  illustrated  in  table  1.  The  eight  subjects 
were  divided  into  two  groups.  Because  testing  time  in  the  Host/PVD  Data  Link  test  bed  was  available 
only  in  the  late  afternoon,  the  experimental  design  was  configured  so  that  ISSS  testing  sessions 
preceded  Host/PVD  testing  sessions  on  each  of  the  two  full  scale  simulation  days.  However,  as 
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TABLE  1.  FULL  SCALE  SIMULATION  EXPERIMENTAL  DESIGN 
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PVD 
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DATA  LINK 

VOICE 
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DATA  LINK 

Scenario  A 

Scenarios 

_ i 

Scenario  A 

_ 

Scenarios 

shown  in  the  table,  the  two  groups  alternated  between  testing  in  the  Host/PVD  Data  Link  test  bed  and 
in  the  ISSS  facility.  This  alternation  counterbalanced  for  order  of  testing  on  the  two  Data  Link 
implementations,  and  minimized  transfers  bet''  cen  the  two  laboratory  facilities.  The  air  traffic 
scenarios  were  partially  counterbalanced  with  the  independent  vaiiables  such  that  both  scenarios  were 
used  under  Data  Link  and  voice  conditions  with  both  system  implementations. 

As  an  auxiliary  control  over  learning  effects  in  the  experimental  design,  all  subjects  participated  in 
warm-up  trials  in  both  the  ISSS  and  Host/PVD  test  facilities.  These  warm-up  runs  were  completed  on 
the  day  before  the  beginning  of  testing  and  consisted  of  abbreviated  versions  of  the  Data  Link  test 
scenarios  using  100  percent  traffic  loads  and  80  percent  Data  Link  equipage. 

Data  were  collected  on  radio  usage  to  obtain  an  index  of  the  extent  to  which  Data  Link  was  used  by 
the  subjects  to  substitute  for  voice  communications  during  the  ISSS  test  trials.  As  subjects  performed 
in  the  ISSS  test  runs,  simulation  computers  recorded  the  number  of  voice  messages  sent  by  each 
controller  and  the  duration  of  each  voice  message.  For  the  purpose  of  this  measurement,  a  voice 
message  was  defined  as  a  microphone  push  to  talk  (PTT)  action  followed  by  a  release  action. 

The  primary  data  that  were  obtained  during  full  scale  simulation  testing  were  based  upon  expert 
judgments  provided  by  the  controller  subjects.  These  data  were  collected  using  quantified  rating 
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techniques,  questionnaires  administered  after  each  test  session,  and  questionnaires  administered  after 
all  of  the  test  sessions  were  completed. 


At  the  termination  of  each  test  run,  each  controller  provided  an  overall  rating  of  the  workload  they 
experienced  during  the  scenario  using  the  Subjective  Workload  Assessment  Technique  (SWAT). 
SWAT  was  developed  in  the  early  1980's  by  the  U.S.  Air  Force  as  a  standardized  method  for 
obtaining  quantified  estimates  of  perceived  workload  in  a  broad  variety  of  occupational  tasks.  The 
technique  has  received  extensive  use  in  simulation  and  operational  testing  environments  within  the 
Department  of  Defense,  and  was  used  successfully  with  air  traffic  controllers  in  prior  en  route  and 
terminal  Data  Link  studies. 

SWAT  is  used  to  rate  the  level  of  workload  experienced  by  a  subject  during  a  preceding  period  of 
work.  Briefly,  SWAT  consists  of  three,  three-point  rating  scales  referring  to  the  dimensions  of  time 
load,  mental  effort,  and  psychological  stress.  Subjects  indicate  the  workload  associated  with  an 
activity  by  marking  the  appropriate  point  on  each  scale. 

A  unique  feature  of  this  workload  measurement  technique  is  that  the  three  ordinal  ratings  that  are 
obtained  are  converted  to  single  points  on  an  overall  interval  measurement  scale.  The  conversion  uses 
a  mathematical  analysis  method  known  as  conjoint  measurement  which  produces  values  ranging  from 
0  (low  workload)  to  100  (high  workload).  This  method  not  only  yields  data  which  are  amenable  to 
parametric  statistical  testing,  but  also  tailors  the  measurement  scale  to  each  individual's  (or 
homogeneous  group's)  concept  of  how  the  time,  effort  and  stress  dimensions  combine  to  produce  the 
overall  perception  of  workload. 

The  interval  scale  used  to  interpret  the  ordinal  ratings  is  created  by  having  subjects  generate  an 
ordering  of  all  27  combinations  of  the  time,  effort,  and  stress  levels  on  the  scales.  This  ordering 
reflects  their  individual  concepts  of  how  the  three  dimensions  combine  to  produce  different  workload 
levels.  The  card  sorting  task  used  during  the  scale  development  exercise  was  completed  by  all  eight 
subjects  in  this  study  during  a  prebriefing  session.  The  SWAT  rating  scale  is  included  in  appendix  C 
along  with  instmctions  provided  to  subjects  during  the  scale  development  exercise. 

After  completing  a  SWAT  rating  the  subjects  also  were  asked  to  note  any  factors  which  contributed  to 
the  workload  perceived  during  the  run.  On  Data  Link  trials  they  were  prompted  to  comment  on  any 
operational  problems  that  they  experienced  which  were  associated  specifically  with  using  the  Data 
Link  services. 

2.3.3.5  Post  Test  Evaluations. 

After  finishing  all  four  test  runs,  the  subjects  completed  two  sets  of  ratings.  These  ratings  were 
designed  to  obtain  projective  estimates  of  Data  Link  impact  on  controller  and  system  performance, 
and  to  generate  a  summary  evaluation  of  each  of  the  candidate  ISSS  Data  Link  service  designs. 

In  the  first  set  of  ratings,  the  subjects  were  asked  to  estimate  the  way  in  which  the  introduction  of 
Data  Link  and  ISSS  would  impact  general  ATC  performance  in  an  actual  operational  implementation. 
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These  ratings  were  designed  to  separate  the  effects  of  general  differences  between  the  Host/PVD  and 
ISSS  conunon  console  systems  from  those  of  the  two  Data  Link  implementations.  A  sample  of  the 
rating  form  used  to  obtain  the  projective  judgments  is  presented  in  appendix  C. 

Projective  estimates  were  solicited  for  each  of  four  factors;  (1)  controller  workload;  (2)  controller 
efficiency/productivity;  (3)  system  capacity;  and  (4)  system  safety.  For  each  factor,  the  respondents 
made  all  six  comparisons  between  pairs  of  the  four  test  conditions: 

Host/PVD  -  voice 
Host/PVD  -  voice  and  Data  Link 
ISSS  -  voice 

ISSS  -  voice  and  Data  Link 

In  each  comparison,  they  could  rate  the  two  members  of  the  pair  as  equal  on  the  factor  (e.g., 
woildoad),  or  judge  either  of  the  two  as  "somewhat"  or  "much  higher"  on  that  dimension.  The 
resulting  data  were  transformed  by  using  the  Analytical  Hierarchy  Process  (AHP)  (Saaty,  1980)  to 
produce  ratio  scale  values  for  each  test  condition. 

In  the  second  set  of  post  test  ratings  the  controllers  evaluated  each  of  the  five  service  designs  on  two 
factors  (see  forms  in  appendix  C.).  The  first  scale  required  the  subjects  to  assess  the  operational 
effectiveness  and  suitjfcility  of  the  service  design.  The  data  form  permitted  the  subject  to  rate  a  service 
as  "not  operationally  suitable,"  or  on  a  7-point  scale  ranging  from  1  "minimally  effective"  to  7  "highly 
effective."  Instructions  for  completing  this  scale  asked  the  subjects  to  use  their  experience  in  the  Data 
Link  Test  Bed  and  their  prior  background  in  en  route  ATC  operations  to  assess  how  well  each  service 
design  could  accomplish  its  intended  task  in  the  full  range  of  potential  field  environments. 

The  second  rating  was  an  estimate  of  the  acceptability  and  preferability  of  each  of  the  service  designs 
to  air  traffic  controllers.  The  data  form  permitted  the  subjects  to  rate  a  service  as  "completely 
unacceptable,"  or  on  a  7-point  scale  ranging  from  1  "acceptable,  but  not  preferred"  to  7  "highly 
preferred."  Instructions  directed  the  subjects  to  consider  the  extent  to  which  the  displays,  input 
requirements,  and  procedures  used  to  deliver  a  service  would  be  useable  by  air  traffic  controllers. 

Additional  explicit  instructions  for  these  two  scales  indicated  that  the  dimensions  of  effectiveness  and 
preference  should  be  treated  independently,  since  a  service  might  include  all  functions  needed  to  meet 
operational  requirements  and  still  be  poorly  suited  to  the  way  in  which  controllers  perform  their 
functions.  Likewise,  a  design  could  be  easy  to  use,  but  have  missing  features  which  prevent  it  from 
meeting  operational  needs. 

2.3.3.6  Final  Debriefing. 

A  final  debriefing  followed  the  full  scale  simulation  testing.  This  debriefing  revisited  the  design  of  the 
candidate  ISSS  services  to  solicit  any  additional  recommendations  regarding  changes.  The  debriefing 
also  was  used  as  a  forum  for  the  subject  controllers  to  discuss  issues  in  the  development  of  Data  Link 
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and  to  express  any  final  comments  or  concerns  regarding  the  general  operational  impact  of 
implementing  Data  Link  ATC  services  in  the  NAS. 

3.,  TESTRESULT3- 

3. 1  ISSS  PROTOTYPE  SIMULATION  SYSTEM  EVALUATION. 

One  of  the  objectives  of  this  first  study  of  ISSS  Data  Link  ATC  services  was  to  validate  the  fidelity  of 
the  system  used  to  exercise  the  candidate  service  designs  within  the  context  of  dynamic  ATC 
simulations.  Unlike  earlier  en  route  studies  in  which  simulations  were  carried  out  on  operational  PVD 
workstations,  development  of  Data  Link  for  the  pre-operational  ISSS  required  the  use  of  prototype 
hardware  and  software  which  were  not  designed  to  be  a  precise  copy  of  the  actual  system,  or  to 
provide  all  of  its  functionality.  Thus,  it  was  necessary  to  ensure  that  the  prototype  faithfully 
reproduced  those  aspects  of  the  ISSS  that  may  affect  controllers’  Data  Link  performance  or  the 
judgments  they  would  be  asked  to  make  about  Data  Link  during  simulation  testing.  To  evaluate  that 
capability,  the  subjects  in  this  study  completed  a  questionnaire  and  participated  in  a  group  discussion 
after  completion  of  the  training  and  practice  sessions. 

The  overall  response  to  the  prototype  system  was  very  favorable,  and  subjects  with  the  highest  level  of 
ISSS  experience  noted  that  its  capabilities  were  in  many  ways  superior  to  equipment  and  software  that 
they  had  worked  with  during  ISSS  design  evaluations.  Detailed  results  are  discussed  in  the  following 
subsections. 

3.1.1  Prototype  Hardware. 

When  asked  to  assess  the  realism  of  the  prototype  hardware  including  the  common  console  design, 
input  devices,  display  surface  and  audio  communications  system,  all  eight  subjects  agreed  that  the 
prototype  provided  sufficient  realism  to  support  Data  Link  development.  Individual  comments 
included  one  recommendation  that  a  foot  pedal  microphone  switch  be  added  for  the  audio 
communications  system.  In  addition,  two  controllers  from  the  ATDLVT  noted  that  the  uncon¬ 
ventional  layout  of  the  numeric  entry  pad  on  the  keyboard  made  it  difficult  to  use.  However,  it  should 
be  noted  that  the  keyboards  were  actual  ISSS  units.  Thus,  these  criticisms  were  not  relevant  to 
evaluation  of  the  prototype  system's  fidelity. 

3.1.2  Screen  Graphics  and  Text. 

All  of  the  subject  controllers  rated  the  appearance  of  the  screen  graphics  and  text  as  sufficiently 
realistic.  This  unanimous  opinion  included  the  fidelity  of  color  coding,  view  design,  and  all  other 
visual  representations. 

3. 1 .3  Dynamic  Aspects. 

The  controllers  also  were  asked  to  assess  the  realism  of  the  dynamic  aspects  of  the  prototype 
simulator  in  terms  of  system  response  lime  to  controller  inputs  and  the  movement  of  aircraft  tracks  on 


17 


the  situation  display.  While  five  of  the  subjects  rated  the  prototype  as  being  sufficiently  realistic,  the 
remaining  three  subjects  indicated  that  aircraft  maneuvering  characteristics  were  noticeably  different 
from  those  observed  in  actual  operational  conditions. 

Subsequent  group  discussion  of  this  criticism  suggested  that,  while  the  realism  of  aircraft  movement  in 
the  prototype  was  equivalent  to  that  provided  by  the  DYSIM  training  function  used  in  operational 
ARTCCs,  higher  fidelity  in  the  prototype  system  would  be  desirable.  Further  examination  of 
simulation  characteristics  that  would  improve  dynamics  indicated  that  changes  in  aircraft  performance 
models  and  in  the  pseudopilot  interface  would  be  desirable. 

Several  subjects  noted  that  the  pseudopilots  were  sometimes  unable  to  keep  pace  with  entering  aircraft 
clearances  to  the  workstation  in  response  to  controller  commands.  For  the  present  study,  this  problem 
was  solved  before  subsequent  full  scale  simulation  exercises  by  adding  a  second  operator  to  each 
pseudopilot  workstation.  However,  it  was  recommended  that  a  long  term  solution  will  require  an 
analysis  of  potential  workstation  interface  modifications  to  ease  data  entry. 

The  controllers  also  suggested  that  capabilities  be  added  to  the  pseudopilot  workstations  to  permit 
more  realistic  aircraft  responses  to  clearances  involving  a  crossing  restriction  with  a  speed  stipulation. 
Because  the  simulation  system  did  not  provide  a  display  of  the  aircraft's  position  with  respect  to  the  fix 
location,  the  pseudopilots  were  forced  to  reduce  speeds  immediately  upon  receiving  the  message.  The 
controllers  indicated  that  this  resulted  in  an  unrealistic  situation  since  actual  pilots  would  initiate  the 
speed  reduction  much  closer  to  the  fix. 

Improvements  to  the  computerized  aircraft  models  also  were  suggested  by  the  subjects  to  more  closely 
approximate  actual  aircraft  changes  in  speeds,  climb  and  descent  rates,  and  turn  rates.  The  test 
controllers  felt  that  these  tended  to  occur  too  quickly  in  the  simulation,  and  that  more  variability  in 
profiles  attributable  to  aircraft  types  and  company  procedures  would  make  controller  workload  levels 
more  realistic. 

3. 1 .4  Views.  Functions  and  Command  Inputs. 

Six  of  the  eight  subjects  indicated  that  the  ISSS  functions  and  views  made  available  by  the  ISSS 
prototype  in  this  study  were  sufficiently  realistic  and  adequate  to  support  future  Data  Link  testing. 
However,  one  controller  from  the  ERST,  and  one  controller  from  the  ATDLVT  (who  had 
comparatively  more  prior  ISSS  experience  than  other  team  members)  suggested  additions.  These 
included: 

a.  Presentation  of  the  fourth  line  of  the  FDB  as  defined  for  the  ISSS; 

b.  Addition  of  the  "halo"  function  used  as  a  callable  visual  aid  for  maintaining  aircr«ui  separation; 

c.  The  ISSS  message  recall  command  permitting  display  of  the  last  message  entered  in  the  message 
composition  (MC)  view; 
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d.  The  ISSS  view  expand/contract  and  enlarge/reduce  functions; 

e.  The  ISSS  view  which  presents  current  vector  length,  range  and  leader  line  length  settings;  and 

f.  Activation  of  the  keyboard  filter  keys,  especially  the  map  filters. 

A  final  important  change  for  future  Data  Link  simulations  that  was  discussed  during  the  debriefing  was 
the  addition  of  console  positions  for  the  "D"  and  ”T"  controllers.  ERST  members  noted  that  current 
concepts  of  operation  for  the  ISSS  call  for  these  controllers  to  play  new  roles  which  do  not  exist  in  the 
Host/PVD  enviromnent,  and  which  are  likely  to  affect  Data  Link  use  and  assignment  of 
responsibilities.  In  particular,  the  assistant  controllers  will  be  increasingly  involved  with  the 
monitoring  and  manipulation  of  electronic  flight  strips  and  flight  data  entries  unique  to  the  ISSS.  Such 
changes  are  expected  to  affect  the  overall  responsibilities  and  tasking  in  en  route  ATC  which  could 
affect  the  results  of  future  Data  Link  testing.  They  were  also  seen  by  these  controllers  as 
opportunities  to  integrate  Data  Link  activities  with  the  new  task  assignments  and  display  opportunities 
associated  with  ISSS. 

12  . .ISSS  CANDIDATE  DATA  LINK  SERVICE  DESIGN  REVIEW. 

The  chief  goals  of  this  study  were  to  evaluate  the  candidate  designs  for  initial  ISSS  Data  Link  ATC 
services  and  to  obtain  recommendations  for  enhancements  of  the  human-computer  interface  and 
procedures.  Data  collected  in  pursuit  of  these  goals  were  obtained  primarily  fiom  the  design  review 
exercise,  and  secondarily  from  summary  evaluations  of  operational  suitability  and  controller- 
acceptance  (see  section  3.3). 

The  following  subsections  present  data  obtained  from  the  individual  design  review  booklets  and  fiom 
the  subsequent  debriefing  sessions. 

3.2. 1  Message  Status  Displays  and  Entry  Error  Messages. 

Prior  FAA  Technical  Center  research  conducted  for  both  the  en  route  Host/PVD  and  the  terminal 
Automated  Radar  Terminal  System  (ARTS)  IIIA  systems,  has  clearly  shown  that  controllers  require 
feedback  on  message  content  and  information  about  message  status  during  an  ongoing  Data  Link 
transaction.  In  service  designs  developed  and  tested  for  both  of  these  ATC  environments,  this 
information  is  presented  in  a  status  list,  and  in  some  instances,  in  the  FDB.  Additionally,  both  designs 
use  a  set  of  graphic  symbols  displayed  in  the  first  line  of  the  FDB  to  indicate  an  aircraft's  Data  Link 
equipage,  and  the  eligibility  of  the  control  position  to  communicate  with  the  aircraft  via  Data  Link. 

The  candidate  service  designs  for  the  ISSS  were  developed  in  accordance  with  these  general  design 
principles,  including  a  Data  Link  status  list  view,  FDB  status  and  content  displays  for  altitude 
clearances  and  TOC  modeled  after  the  Host/PVD  design,  and  graphic  symbology  for  Data  Link 
equipage/eligibility.  Individual  design  review  responses  to  the  design  of  the  status  list  view  and  the 
FDB  displays  are  discussed  below  in  conjunction  with  relevant  group  debriefing  results. 
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3.2. 1.1  Status  List. 

All  eight  subjects  indicated  that  the  status  list  is  a  necessary  feature  of  the  Data  Link  design.  The 
primary  reasons  cited  for  this  requirement  were  that  the  status  list  was  used  for  some  transactions  that 
provided  no  FDB  display,  and  that  it  was  used  in  the  design  as  the  sole  means  for  uplinking  a  "held" 
TOC  OKSsage  by  slewing  the  cursor  to  the  appropriate  list  entry.  However,  some  of  the  subject 
controllers  noted  that  even  if  these  functions  could  be  handled  in  other  ways,  the  status  list  had 
additional  desirable  attributes  that  justified  its  inclusion  in  the  design.  In  particular,  two  subjects 
indicated  that  it  would  serve  as  a  coordination  display  for  "D"  and  "T"  control  positions.  Three  others 
noted  that  it  acts  as  a  valuable  backup  to  abbreviated  FDB  status  displays  by  providing  more  persistent 
wilco  status  information,  more  complete  message  content  information,  and  a  "message  sent"  indication 
that  can  be  placed  in  close  proximity  to  the  MC  view  to  act  as  immediate  feedback  when  uplink 
commands  are  typed. 

All  of  the  subjects  also  concurred  that  the  status  message  abbreviations,  service  type  abbreviations  and 
yellow  alert  codes  used  in  the  status  list  design  were  acceptable.  One  subject  expressed  a  desire  to 
improve  alert  coding  of  a  message  that  had  received  an  unable  or  standby  response,  or  had  timed  out. 
Subsequent  group  discussion  produced  a  recommendation  that  the  entire  line  of  the  transaction  be 
displayed  in  yellow  rather  than  just  the  UNA,  STB,  or  TIM  status  abbreviation.  The  subjects  also 
concurred  that  the  standard  ISSS  view  commands  used  to  move,  suppress,  and  recover  the  status  list 
view  were  appropriate  and  easy  to  perform. 

The  subjects  were  in  agreement  that  the  status  list  should  be  a  secondary  display  of  message  status  and 
content  which  is  normally  more  detailed  than  the  FDB  display.  In  order  to  permit  controllers  to  tailor 
the  display  to  individual  needs  and  to  reduce  clutter,  the  group  recommended  that  functions  be  added 
to  provide  selective  suppression  by  service/message  type  and  to  control  the  duration  of  the  wilco 
status  display  by  control  position.  In  addition,  the  page/scroll  commands  available  in  other  ISSS  views 
were  suggested  as  valuable  improvements. 

3.2.1.2  FDB  Displays. 

The  candidate  design  used  a  graphic  symbol  in  the  first  position  of  the  first  line  of  the  FDB  as  an 
equipage/eligibility  display.  An  open  diamond  indicated  the  existence  of  a  Data  Link  connection 
between  the  aircraft  and  ground  system.  A  filled  diamond  indicated  that  the  connection  existed,  and 
that  the  viewing  control  position  was  eligible  to  communicate  with  the  aircraft.  One  of  the  subjects 
initially  noted  that  the  diamond-shaped  symbols  might  be  confused  with  an  aircraft  position  symbol  on 
the  situation  display.  However,  the  group  consensus  was  that  these  codes  should  be  retained.  The 
group  also  reconunended  that  inquiries  be  initiated  to  insure  that  the  filled  diamond  symbol  will  be 
available  for  use  in  the  actual  ISSS. 

Significantly,  the  full  group  recommended  that  status  and  content  information  be  included  in  the  FDB 
for  all  control  messages.  A  detailed  discussion  of  this  finding  is  presented  in  section  3.2.5. 1. 
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3.2.  L3  Entry  Error  Messages. 

Specialized  messages  were  developed  for  the  candidate  ISSS  services  to  denote  data  entry  errors 
specific  to  Data  Link  functions.  In  accordance  with  ISSS  conventions,  these  error  messages  were 
displayed  in  the  MC  view  when  an  attempt  was  made  to  enter  a  faulty  message,  and  a  special  keyboard 
input  was  required  to  delete  the  faulty  message  and  the  error  message  prior  to  retyping. 

Four  of  the  subjects  indicated  that  the  phrasing  and  display  of  the  error  messages  were  acceptable. 
However,  the  remaining  controllers  suggested  changes.  Two  felt  that  a  more  salient  indication  was 
needed  to  emphasize  that  a  Data  Link  message  had  not  been  sent  because  of  an  entry  error.  Both 
noted  that  some  type  of  FDB  alert  would  serve  this  function.  Two  controllers  also  expressed  a  desire 
to  shorten  or  reword  some  of  the  error  messages. 

During  group  debriefing,  a  unanimous  position  was  adopted  regarding  a  change  to  the  entry  used  to 
clear  an  error  message.  This  keyboard  input  is  required  in  ISSS  specifications,  presumably  to  allow 
for  the  editing  of  faulty  messages  in  the  MC  view  as  an  option  to  retyping.  The  controllers 
participating  in  the  present  study  felt  that  brief  Data  Link  niessages  will  not  be  edited,  and  that 
requiring  tte  clear  entry  before  retyping  will  produce  an  unacceptable  increase  in  data  entry  time. 

3.2.2  TOC. 

3.2.2. 1  Mode  Indicator. 

The  candidate  design  for  TCKJ  permitted  the  controllers  to  operate  this  service  in  either  an  automatic 
or  manual  mode.  In  the  automatic  mode,  the  message  containing  the  new  frequency  was  uplinked 
when  the  receiving  control  position  accepted  the  sector  hand  off.  In  the  manual  mode,  the  message 
was  held  as  an  item  in  the  status  list  until  the  controller  initiated  the  uplink  by  making  a  slew  entry  to 
designate  the  item.  The  controller  selected  the  desired  mode  by  a  keyboard  entry. 

While  this  general  design  was  acceptable  to  all  of  the  controllers,  they  also  agreed  on  the  need  for  an 
additional  display  to  provide  a  continuous  indication  of  the  active  TCXT  mode.  The  group  concurred 
that  the  most  acceptable  location  for  this  display  would  be  the  header  area  of  the  status  list  view. 
However,  it  was  noted  that  unless  the  status  list  is  defined  as  a  view  which  must  be  displayed  at  all 
times,  the  mode  indication  would  not  be  available  if  the  controller  chose  to  suppress  this  view. 

3.2.2.2  Message  Failure  Display. 

All  eight  subjects  agreed  that  replacing  the  equipage/  eligibility  symbol  in  the  first  line  of  the  FDB  with 
an  up-arrow  symbol  was  a  desirable  method  to  indicate  that  a  TOC  message  had  been  sent.  However, 
six  controllers  felt  that  the  symbology  used  to  indicate  failure  of  the  TOC  process  was  inadequate. 

In  the  candidate  design,  the  receipt  of  an  unable  response  from  the  pilot,  or  the  expiration  of  the 
transaction  timer  (time  out),  caused  the  up-arrow  to  revert  to  a  filled  diamond  in  the  sending 
controller's  FDB  indicating  that  the  position  had  retained  eligibility.  The  diamond  was  color  coded  in 
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yellow  to  alert  the  controller.  Some  controllers  expressed  dissatisfaction  with  this  design  and 
suggested  that  the  alert  be  more  salient  to  insure  prompt  action.  Suggested  solutions  included 
increasing  the  size  of  the  diamond  as  a  redundant  signal  correlated  with  the  color  change,  and  the  use 
of  yellow  alert  coded  UNA  and  TIM  abbreviations  in  the  FDB  similar  to  those  used  in  the  candidate 
AA  service.  Subsequent  discussion  favored  the  use  of  the  FDB  display  of  TIM  and  UNA.  The  group 
strongly  recommended  that  these  be  adopted  for  all  services.  In  addition,  while  reversion  of  the  up- 
arrow  to  the  yellow-filled  diamond  was  seen  as  an  appropriate  redundant  code  for  TOC,  the  group 
recommended  that  it  be  used  only  with  an  unable  response  since  a  time  out  event  does  not  close  the 
transaction.  In  this  case,  the  FDB  TIM  display,  along  with  a  change  in  the  up-arrow  color  code  to 
yellow,  was  suggested  as  a  possible  solution. 

12.2.3  Methods  for  Sending  Held  Messages  in  Manual  Mode. 

As  described  in  section  3.2.2. 1  above,  the  candidate  design  required  a  slew  entry  to  the  status  list  item 
to  send  a  held  TOC  message  when  operating  in  the  manual  mode.  Individual  evaluations  derived  from 
the  design  review  booklets  revealed  several  suggestions  for  enhancing  the  flexibility  and  ease  of 
sending  these  held  messages.  In  subsequent  discussions,  the  group  agreed  that  several  options  should 
be  provided  as  alternatives  to  the  status  list  slew  entry.  These  included  a  slew  entry  to  the  FDB 
preceded  by  a  Data  Link  key  entry,  or  a  keyboard  entry  of  the  Aircraft  Identification  (AID)  or 
Computer  Identification  (CID). 

As  a  potential  aid  to  selecting  and  sending  TOC  messages,  the  subjects  also  recommended  that  future 
studies  test  the  option  of  displaying  all  held  message  items  in  the  status  list  as  a  single  group  separate 
from  other  ongoing  transactions. 

3.2.2.4  Force  and  Steal  Eligibility  Inputs. 

Based  on  the  results  of  earlier  studies  of  the  Host/PVD  en  route  Data  Link  requirements,  the  candidate 
ISSS  design  for  TOC  provided  command  options  which  permitted  controllers  to  force  Data  Link 
eligibility  to  another  sector.  It  also  provided  an  ability  to  acquire  eligibility  (steal)  without  a  hand  off. 
To  aceommodate  procedures  used  in  some  ARTCCs,  both  of  these  commands  provided  for  an 
optional  suffix  (S)  to  send  the  appropriate  TOC  message  to  the  affected  aircraft. 

Although  the  operational  requirements  for  these  features  were  recognized  by  the  subjects,  concerns 
expressed  the  need  for  strict  adherence  to  procedures  to  ensure  they  were  used  safely.  In  particular,  it 
was  noted  that  the  design  could  permit  inadvertent  separation  of  voice  radio  and  Data  Link 
communications  at  two  different  sectors. 

Since  the  frequency  change  message  and  eligibility  will  be  correlated  in  the  vast  majority  of  situations, 
the  group  recommended  that  the  possibility  of  error  could  be  minimized  through  design  by  modifying 
the  force  and  steal  commands.  Under  this  recommendation,  sending  the  TOC  message  would  occur 
by  default  when  forcing  or  stealing  eligibility.  An  optional  suffix  (I)  would  be  required  to  inhibit  the 
uplink  normally  associated  with  the  eligibility  change. 
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Two  new  command  inputs  were  recommended  by  the  subjects  during  group  discussion  to  enhance  the 
usability  of  the  TOC  service.  In  order  to  simplify  the  inputs  needed  to  acquire  track  control  from 
another  sector  without  an  offered  hand  off  and  to  subsequently  acquire  Data  Link  eligibility,  the 
controllers  suggested  that  a  single  command  be  developed  to  accomplish  both  operations 
simultaneously.  Additionally,  the  group  agreed  to  extensions  to  the  existing  conunand  suffix  (S) 
which  permits  the  controller  to  automatically  send  the  TOC  message  to  a  designated  aircraft  while 
operating  in  the  manual  mode.  These  enhancements  would  include  a  suffix  (I)  to  inhibit  an  automatic 
uplink  to  a  designated  aircraft  while  operating  in  the  manual  mode.  Another  enhancement  would  be 
the  capability  to  inhibit  the  uplink  to  all  aircraft  being  transferred  to  a  selected  sector  while  operating 

•  in  the  automatic  mode. 

.  12.3-  AA- 

The  individual  evaluations  and  group  discussion  of  the  AA  service  indicated  that  the  candidate  design 
was  among  the  most  mature  of  those  tested  in  this  study.  All  eight  subjects  agreed  that  the  inputs  to 
manually  enter  and  uplink  assigned  and  interim  altitudes  were  appropriate,  and  that  the  FDB  display  of 
the  content  and  status  of  the  message  provided  useful  and  adequate  feedback.  The  subjects  also 
agreed  that  the  FDB  alerting  displays  for  unable  and  standby  responses  and  expiration  of  the  response 
timer  (time  out)  were  adequate. 

Asked  if  they  foresaw  any  significant  possibility  that  controllers  would  make  undetected  errors  when 
uplinking  altitudes  using  this  service,  none  of  the  subjects  indicated  that  errors  would  be  any  more 
common  with  Data  Link  than  voice.  During  discussion,  the  controllers  suggested  that  the  potential  for 
error  might  be  reduced  even  further  by  adding  reasonableness  checks  to  the  software.  Ihese  could 
include  tests  for  cardinal  altitude  values  and  restrictions  for  the  altitude  boundaries  of  the  sector. 

3.,2.3. 1  Deletion  of  Message  "Failure”  Displays. 

The  single  major  change  recommended  for  this  candidate  design  concerned  the  procedures  used  to 
delete  the  displays  of  these  failure  events  and  close  the  transaction.  As  dictated  by  tl^  Minimal 

,  Operating  Performance  Standards  (MOPS)  for  Data  Link,  an  unable  response  from  the  aircraft 

automatically  closes  a  transaction,  while  a  standby  response  is  an  interim  state  which  keeps  the 
transaction  open  and  which  may  be  followed  by  a  wilco  or  unable.  Likewise,  the  time  out  is  an  alert 

*  that  a  greater  than  normal  period  of  time  has  passed  since  uplinking  a  message  without  receiving  a 
pilot  response.  The  time  out  alert  display  is  based  on  the  expiration  of  a  ground-based  timer  which 
does  not  close  the  transaction. 

The  controllers  indicated  that,  to  prevent  inadvertent  errors,  different  inputs  should  be  used  to  delete 
closed  transactions  (e.g.,  unable  responses),  and  those  which  remain  in  an  open  state  (sent,  standby, 
time  out).  The  unanimously  recommended  solution  was  to  retain  the  candidate  design's  delete 
command  for  unable  displays,  but  to  require  a  logic  override  prefix  to  the  delete  conunand  (e.g.,  /OK) 
to  permit  closure  of  open  transactions  and  removal  of  the  associated  alert  or  status  displays. 
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Along  with  this  modification  to  the  delete  procedure,  the  subjects  also  considered  the  technical 
feasibility  of  a  special  feature  of  the  ISSS  candidate  services  which  permitted  the  controller  to 
designate  more  than  one  aircraft  as  the  receiver  of  a  single  altitude,  TOC,  or  MT  message.  This 
feature  was  favorably  reviewed  by  the  subjects.  However,  subjects  from  the  ERST  noted  that,  while 
current  ISSS  procedures  allow  specification  of  multiple  flight  identifications  (FLlD)’s  on  system  hand 
off  inputs,  they  are  not  permitted  on  other  system  updates,  such  as  AAs.  The  subjects  reconunended 
that  this  issue,  along  with  the  automatic  error  message  delete  requirement  discussed  in  section  3.2. 1.3, 
be  further  investigated.  If  warranted  by  these  investigations,  appropriate  recommendations  to  ISSS 
developers  should  be  formulated  to  accommodate  both  changes. 

3.2.£  IC. 

As  tested  in  this  study,  the  candidate  IC  service  was  accomplished  by  the  pilot  appending  the  aircraft's 
currently  assigned  altitude  to  the  wilco  downlink  response  to  a  TCXT  message.  This  value  was 
automatically  compared  to  the  assigned  altitude  in  the  NAS  data  base  or  the  interim  altitude  in  the 
FDB.  If  no  discrepancy  was  detected,  the  service  was  essentially  transparent  to  the  receiving 
controller.  However,  if  the  downlinked  altitude  differed  from  the  altitude  held  by  ATC,  the 
downlinked  value  was  timeshared  in  the  FDB  in  tl^  altitude  field,  and  a  yellow  alert  coded  "E" 
tqipeared  in  the  confcMmance  indicator  field.  If  the  aircraft  failed  to  downlink  the  altitude  with  the 
TOC  wilco,  "NALT"  was  displayed  in  yellow  in  the  altitude  field. 

3.2.4.  t  False  Alarms. 

The  basic  IC  design  was  Judged  to  be  acceptable  by  the  controllers.  All  subjects  indicated  that  the 
error  alerts  were  adequate,  and  that  the  procedures  used  to  clear  the  error  displays  were  ^propriate. 
However,  because  of  operational  procedures  that  are  widely  used  in  sectors  handling  departures  out  of 
approach  control  facilities,  the  group  unanimously  rejected  the  testing  logic  of  the  automated  altitude 
comparison  feature. 

i 

I 

I  Specifically,  as  aircraft  transition  through  en  route  departure  sectors,  low  altitude  sectors,  and  into 

I  high  altitude  sectors,  controllers  are  not  typically  required  to  update  the  FDB  on  temporary  altitudes 

'  sent  to  the  aircraft.  In  the  candidate  design  logic,  this  situation  would  produce  mismatch  error 

displays  for  nearly  all  aircraft.  Such  a  high  false  alarm  rate  would  at  best  cause  distraction  and  an 
increase  in  controller  workload  associated  with  clearing  the  alert,  and  at  worst  could  lead  to 
complacence  and  a  resulting  failure  to  detect  legitimate  errors. 


Because  automating  the  IC  procedure  was  viewed  by  the  test  controllers  as  a  valuable  Data  Link 
benefit,  they  proposed  an  alternative  approach  to  designing  the  test  logic  that  would  reduce  false 
alerts.  In  this  proposal,  the  automation  would  first  test  the  downlinked  value  against  any  interim 
altitude  displayed  in  the  FDB.  If  no  interim  altitude  was  displayed,  the  system  would  compare  the 
assigned  altitude  in  the  NAS  database  with  the  appropriate  value  contained  in  a  table  of  normal 
departure  altitudes.  It  would  make  the  final  error  test  by  comparing  the  downlinked  value  with  the 


value  in  the  normal  table,  if  the  normal  table  value  was  lower  than  the  assigned  altitude  in  the 
database,  llie  final  error  test  would  be  made  against  the  assigned  altitude  if  that  value  were  lower. 


The  table  of  normal  departure  altitudes  would  be  created  by  defining  areas  in  adaptation  based  on 
altitude  strata.  For  each  stratum,  typical  altitude  clearances  for  departures  would  be  entered  based  on 
aircraft  type  (jet,  turboprop,  etc.). 

3,2.?  MI. 

The  candidate  MT  function  permitted  the  controller  to  select  predefined  messages  for  uplink  from  a 
menu  designed  as  an  ISSS  view.  Messages  were  displayed  in  list  format.  Each  line  contained  an 
alphabetic  item  identifier,  a  two-letter  indicator  of  message  type,  and  an  abbreviated  presentation  of 
the  message.  Message  types  included  AAs,  interim  altitudes,  and  text  messages.  Messages  could  be 
selected  for  uplink  by  typing  the  message  identifier  or  by  trackball  slew  entry. 

Evaluations  of  the  menu  format  were  favorable.  All  subjects  agreed  that  the  two-letter  message  type 
identifier  was  useful,  but  concurred  that  AAs  and  interim  altitudes  should  use  the  identifiers  "AA"  and 
"lA"  rather  than  the  "QQ"  and  "QZ"  abbreviations  associated  with  the  PVD  keyboard. 

3.2.5. 1  FDB  Displays  for  All  Control  Clearances. 

All  of  the  primary  objections  to  the  candidate  MT  design  focused  on  the  message  status  and  content 
displays.  While  AAs  and  interim  idtitudes  in  the  menu  used  FDB  displays  that  were  identical  to  those 
used  for  the  AA  service,  no  FDB  content  or  status  display  was  provided  for  text  items. 

The  decision  to  limit  the  text  message  status/content  display  to  the  status  list  in  the  candidate  ISSS 
design  was  based  on  earlier  Host/PVD  Data  Link  research  in  which  this  message  type  was  developed 
for  informational  and  non-control  messages.  In  the  present  study,  the  text  message  type  also  was  used 
as  a  means  to  provide  controllers  with  an  ability  to  uplink  speed  and  heading  clearances. 

The  subject  controllers  uneuiimously  agreed  that  FDB  status  and  content  displays  would  be  mandatory 
for  all  critical  and  control-related  messages.  They  specifically  noted  that  speed  and  heading  messages 
should  have  FDB  displays  comparable  to  those  provided  by  the  candidate  design  for  altitude 
clearances,  and  that  these  should  be  consistent  across  service  types.  Recommended  elements  of  the 
displays  included  direct  numeric  indication  of  message  content,  status  abbreviations,  and  alert  codes. 

The  argument  for  self-sufficient  FDB  content  md  status  displays  for  all  control  clearances  was 
supported  by  specific  input  from  subjects  drawn  from  the  ERST.  These  individuals  noted  that  the 
large  number  of  important  views  that  controllers  will  need  in  the  ISSS  ATC  environment  will  make 
display  "real  estate"  scarce.  Thus,  every  effort  should  be  taken  to  make  critical  Data  Link  functions 
operable  without  reliance  on  the  status  list  view. 
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In  a  discussion  of  approaches  for  developing  FDB  status  and  content  displays  for  speed  and  heading 
clearances,  group  suggestions  included  possible  use  of  fields  in  the  fourth  line  of  the  ISSS  FDB,  and 
timesharing  or  temporarily  overriding  correlated  data  fields  in  lines  two  and  three  of  the  FDB. 


3.2.5.2  Manual  Speed  and  Heading  Entries. 

The  controllers  also  recommended  that,  in  addition  to  the  menu  method  for  uplinking  predefined 
clearances,  manual  keyboard  entry  methods  for  sending  speeds  and  headings  be  developed  using  the 
candidate  AA  service  as  a  model.  Finally,  a  majority  of  the  subjects  did  not  predict  that  the  use  of  the 
menu  to  uplink  clearances  would  result  in  a  significant  potential  for  undetected  entry  error.  However, 
they  reiterated  the  recommendation  that  the  use  of  reasonableness  checks  be  explored. 

32.6..CB..IEres.TsxO- 

The  CB  service  design  permitted  controllers  to  enter  an  unconstrained  string  of  text  for  uplink  to  one 
or  all  aircraft  in  the  airspace  sector.  No  FDB  displays  were  provided.  A  status  list  display  provided 
message  status  and  a  truncated  content  display  consisting  of  the  first  six  characters  of  the  typed 
message. 

Opinions  regarding  the  adequacy  of  the  displays  differed  widely  among  the  subjects  in  the  individual 
design  review  booklets.  While  some  found  that  the  status  list  display  was  adequate,  others  felt  that  an 
FDB  display  of  any  alert  status  would  be  needed.  Likewise,  the  preferred  completeness  of  content 
information  in  the  status  list  varied  from  the  minimal  characters  used  in  the  candidate  design  to  an 
ability  to  access  the  complete  message  by  command  entry. 

Analysis  of  the  subjects'  written  comments  and  group  discussion  indicated  that  these  widely  differing 
views  were  based  on  the  applications  of  the  service  that  had  been  made  by  different  controllers  during 
practice  exercises.  The  service  title  of  "CB"  had  been  adopted  during  prior  research  which  had 
demonstrated  that  free  text  entry  of  messages  tended  to  be  inefficient  and  error  prone.  Because  of 
these  findings,  it  was  recommended  that  the  function  be  used  only  in  a  backup  mode  to  deal  with 
situations  in  which  radio  communication  was  impossible  and  none  of  the  Data  Link  control  services 
provided  the  needed  message. 

Some  subjects  in  the  present  study  used  the  CB  service  to  create  speed  and  heading  clearances  not 
contained  in  the  menu.  In  their  individual  reviews,  these  controllers  were  most  critical  of  the  absence 
of  the  FDB  status  display,  and  the  truncated  content  display  in  the  status  list.  Group  evaluation  which 
followed  an  explanation  reemphasizing  the  intended  backup  use  for  the  service  led  to  two 
recommendations. 

The  group  agreed  that  the  truncated  content  display  in  the  status  list  should  be  retained,  but  that  an 
ability  to  display  the  full  message  in  the  response  area  (RS)  view  by  a  command  input  should  be  added. 
The  controllers  also  recommended  that  an  ability  to  select  multiple  specific  aircraft  as  message 
addressees  be  added  to  the  existing  ability  to  select  one  or  all  aircraft. 


A  final  controller  concern  was  controller  short  term  memory  for  messages  sent  using  Data  Link. 

When  reviewing  Data  Link  displays  of  message  content  and  status,  some  subjects  noted  that  they  had 
experienced  instances  where  they  were  unsure  that  a  clearance  that  they  intended  to  issue  had,  in  fact, 
been  sent.  In  other  cases,  they  could  not  remember  the  content  of  a  message  that  they  confidently 
recalled  having  sent.  Suggested  solutions  included  increasing  the  persistence  of  the  status  list  display 
of  a  message  after  the  aircraft's  wilco  response  had  been  received. 

It  was  noted  that  similar  lapses  in  short  term  memory  had  been  reported  by  terminal  controllers  during 
ARTS  niA  Data  Link  service  development.  Although  the  phenomena  also  occurs  with  voice  radio 
communications,  it  should  be  possible  to  remedy  the  problem  with  Data  Link  by  providing  a  display 
of  an  aircraft's  message  history.  The  solution  used  for  terminal  development  was  a  history  list  of  the 
last  five  transactions  that  could  be  retrieved  for  any  aircraft  by  a  command  input. 

As  a  result  of  this  discussion,  the  group  recommended  the  development  and  testing  of  a  history  display 
for  the  ISSS  Data  Link  services.  Suggested  methods  included  a  history  list  similar  to  the  terminal 
system,  or  annotation  of  the  ISSS  electronic  flight  strip  fields  to  show  updates  that  had  been 
accomplished  via  Data  Link. 

3,3_FULL  SCALE  SIMULATION  TESTING. 

The  full  scale  simulation  phase  of  this  study  was  conducted  primarily  to  provide  a  realistic  set  of  ATC 
experiences  for  making  a  number  of  comparative  and  predictive  Judgments  about  the  impact  of  the 
initial  ISSS  Data  Link  services.  The  test  runs  also  were  used  to  elicit  final  summary  evaluations  of  the 
candidate  ISSS  Data  Link  service  designs,  and  as  an  opportunity  to  collect  quantitative  data  on 
controller  use  of  the  Data  Link  and  voice  communication  channels. 


3.3.1  ISSS  Communications  Performance. 

Many  of  the  benefits  predicted  for  implementing  Data  Link  ATC  services  in  domestic  airspace  have 
been  associated  with  the  increased  communications  capacity  that  they  will  offer  to  controllers  and 
aircrew.  As  previously  noted,  the  simplex  voice  radio  system  has  been  cited  as  a  major  limitation  to 
effective  ATC  operations,  and  the  provision  of  Data  Link  services  is  expected  to  alleviate  this 
communication  bottleneck. 

In  order  to  generate  a  preliminary  estimate  of  the  extent  to  which  the  availability  of  ISSS  Data  Link 
ATC  services  would  reduce  congestion  on  the  radio  channel,  data  were  collected  on  controller  use  of 
the  voice  frequency.  Measures  were  obtained  during  voice  test  trials  and  during  those  in  which  the 
controllers  were  able  to  freely  choose  between  voice  and  Data  Link  communications.  For  each  of  the 
four  airspace  sectors,  simulation  computers  recorded  the  number  of  PTT  microphone  activations  that 
occurred  during  a  50-minute  run  as  a  measure  of  the  number  of  messages  sent  by  a  controller.  In 
addition,  the  computers  accumulated  the  total  time  during  which  the  radio  channel  was  occupied  by  a 
controller  during  a  test  run  by  summing  the  PTT-to-release  intervals. 


As  shown  in  figure  3,  the  subjects’  use  of  Data  Link  for  ATC  communications  dramatically  reduced 
their  reliance  on  the  voice  channel.  The  mean  number  of  voice  messages  per  sector  dropped  from  167 
to  56,  while  total  channel  occupation  time  by  the  controller  was  reduced  from  610  to  189  seconds. 
Statistical  tests  indicated  that  these  reductions  were  highly  significant  (PTT  t  =  6.624,  df  =  7,  p  =  0. 
time  t  =  8.429,  df  =  7,  p  =  0). 

Generalized  as  percentages,  with  80  percent  of  the  aircraft  in  the  scenarios  equipped  with  Data  Link, 
and  without  including  frequency  usage  by  the  simulation  pilots,  the  results  translate  to  a  66  percent 
reduction  in  the  number  of  messages  and  a  69  percent  reduction  in  channel  occupation  time.  It  is 
interesting  to  note  that  these  findings  closely  corroborate  those  obtained  in  earlier  Host/PVD  en  route 
Data  Link  testing  (Talotta,  et  al.,  1990).  In  that  study  where  different  test  scenarios  and  airspace  were 
used,  and  with  a  more  limited  set  of  Data  Link  services,  channel  occupation  time  was  reduced  by  28 
percent  with  20  percent  of  the  aircraft  Data  Link  equipped,  and  by  45  percent  with  70  percent  of  the 
aircraft  Data  Link  equipped. 

3.3.2  Controller  Workload  During  Test  Runs. 

Each  of  the  subjects  completed  the  SWAT  scale  development  task  prior  to  participating  in  the  full 
scale  simulation  test  runs.  The  ordered  card  sorts  generated  by  the  individual  subjects  were  used  as 
input  to  the  SWAT  scaling  algorithms.  The  algorithms  produced  the  unidimensional,  interval  level 
workload  scale  values  that  would  be  used  to  interpret  the  ordinal  ratings  of  1  to  3  on  the  time,  effort 
and  stress  scales. 

The  overall  level  of  agreement  among  subject  orderings  of  the  27  possible  combinations  of  time, 
effort,  and  stress  was  assessed  by  computing  Kendall's  Coefficient  of  Concordance.  The  W  statistic 
attained  a  value  of  0.81,  The  guidelines  developed  for  SWAT  analysis  state  that  values  of  0.75  and 
above  are  indicative  of  a  relatively  homogeneous  group.  Thus,  a  single  scaling  solution  was  used  to 
capture  the  subjects'  composite  view  of  the  way  in  which  the  time,  effort,  and  stress  factors  combined 
to  produce  various  levels  of  workload. 

Axiom  tests  performed  on  the  average  rankings  for  the  eight  controllers  produced  a  minimum  number 
of  violations  under  the  additive  model.  The  final  scale  values  for  transforming  the  ratings  reflected 
approximate  levels  of  importance  of  27  percent  for  time,  28  percent  for  effort,  and  45  percent  for 
stress. 

Instructions  to  the  subjects  emphasized  that  after  completing  each  test  run  they  were  to  rate  the 
overall  workload  that  they  had  actually  experienced.  The  raw  workload  ratings  collected  were 
transformed  to  SWAT  scores  by  referring  to  the  0  to  100  group  scale  described  above.  All  statistical 
analyses  were  performed  on  these  scores. 

A  multivariate  analysis  of  variance  performed  on  the  SWAT  scores  for  each  test  condition  revealed  no 
statistically  significant  difference  in  perceived  workload  between  voice  and  voice  plus  Data  Link 
simulation  runs  (F  1,7  =  2.92,  p  =  .  13).  However,  as  illustrated  in  figure  4,  regardless  of  the 
conununication  system,  the  controllers  rated  their  workload  as  significantly  lower  when  using  the  ISSS 
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common  console  than  when  working  on  the  PVD  workstation  (F  1,7  =  12.4,  p=.009).  The  interaction 
between  ATC  system  type  and  communication  system  was  not  significant  (F  1,7  =  .009,  p  =  .93). 


Written  controller  conunents  suggested  that  a  number  of  factors  affected  perceived  workload  during 
the  100  percent  of  OALT  test  runs.  Of  18  comments,  9  cited  controller  or  simulation  pilot  errors  as 
contributors  to  increased  workload.  Four  noted  problems  with  the  candidate  Data  Link  designs, 
which  included  the  lack  of  FDB  displays  for  speed  and  heading  clearances  identified  during  the  design 
review.  Comments  directly  related  to  communications  noted  Data  Link  improved  time  management, 
especially  with  the  ISSS  designs.  One  subject  also  indicated  that  workload  was  higher  under  voice 
conditions  because  of  pilot  requests  for  message  repeats. 

With  respect  to  the  impact  of  Data  Link  on  workload,  the  SWAT  findings  agree  with  prior  controller 
assessments  obtained  following  test  runs  comparing  voice  radio  communications  to  voice  plus  Data 
Link.  Results  of  earlier  simulation  studies  examining  both  en  route  and  terminal  systems  indicate  that 
controllers'  perceive  their  workload  to  be  no  greater  than  that  experienced  with  voice  radio  alone,  or 
moderately  higher.  Variations  appear  to  depend  on  subject  training  and  familiarity  with  the 
communications  system  and  the  test  airspace.  The  substantially  identical  result  obtained  in  the  present 
study  indicates  that,  even  when  using  the  unrefined  candidate  service  designs,  controllers  find  that 
providing  Data  Link  ATC  services  with  the  ISSS  produces  no  different  workload  effect  on  the  user 
than  that  experienced  on  the  PVD  system. 

Caution  should  be  exercised  when  interpreting  the  reduction  in  workload  reported  by  the  controllers 
when  operating  ISSS.,  It  cannot  be  concluded  from  these  data  that  the  operational  ISSS  will  result  in 
reduced  controller  workload  because  the  prototype  workstation  simulated  only  partial  ISSS 
functionality  for  the  radar  controller  position.  It  did  not  include  the  electronic  flight  strip 
implementation  or  associate  controller  positions.  Nevertheless,  the  finding  is  of  some  interest  since  it 
suggests  that  if  some  controllers  experience  an  increase  in  workload  with  Data  Link  usage,  it  may  be 
ameliorated  by  some  of  the  enhancements  associated  with  the  new  human-computer  interface. 

3.3.3  Projected  Impact  of  Data  Link  and  ISSS. 

Following  all  four  full  scale  test  runs,  the  subjects  were  asked  to  make  a  number  of  final  ratings  aimed 
at  summarizing  and  quantifying  their  overall  perceptions  of  Data  Link.  The  first  was  designed  to 
permit  the  controllers  to  make  projective  evaluations  of  the  impact  of  Data  Link  on  controller  and 
system  performance.  Unlike  the  ratings  made  after  each  test  run,  these  scales  asked  the  subjects  to  use 
their  operational  expertise  and  the  simulation  experiences  as  a  basis  for  predicting  the  impact  cf  Data 
Link  in  an  operational  implementation.  TTiey  were  instructed  to  assume  a  fully  designed  and  tested 
system.  AHP  techniques  were  used  to  obtain  comparative  ratings  of  the  relative  effects  of  the  PVD 
and  ISSS  implementations  under  voice  only  and  voice  plus  Data  Link  communication  conditions  for 
four  variables:  system  capacity,  system  safety,  controller  workload,  and  controller  efficiency/ 
productivity.  For  each  variable,  the  AHP  analysis  was  used  to  produce  relative  values  ranging 
between  0  and  1.0  based  on  all  possible  comparisons  of  the  combination  of  communication  condition 
and  controller  interface  type.  Thus,  the  differences  between  values  on  the  scale  are  meaningful  in 
examining  these  results  rather  than  the  absolute  values. 


SWAT  Workload  Score 


100 

90 

80 

70 


60 

Uod 

50 


Low 


40 

30 

20 

10 

0 


Host/PVD  ISSS 

Controller  Interface 


'Workload  experienced  during  test  trials  -  initial  designs 


HGURE  4.  PERCEIVED  CONTROLLER  WORKLOAD  DURING  ISSS  AND  HOST  PVD 
TEST  RUNS 


Multivariate  analyses  of  variance  were  performed  on  each  of  the  projected  variables.  Neither 
projected  controller  workload  nor  system  capacity  were  found  to  differ  significantly  as  a  function  of 
controller  interface  type  or  the  availability  of  Data  Link  (p>.05). 

Significant  differences  among  the  four  system  combinations  were  detected  for  the  safety  (F  1 .7  =  7. 16, 
p<  .05)  and  controller  efficiency /productivity  (F  1,7  =  87,  p<  .001)  variables.  Figure  5  presents  these 
results  as  AHP  mean  difference  scores  computed  by  subtracting  each  subject's  AHP  value  for  the  PVD 
Data  Link,  ISSS  voice,  and  ISSS  Data  Link  conditions  from  that  obtained  for  the  existing  PVD  voice 
baseline. 

As  shown  in  the  figure,  the  controllers  predicted  relatively  higher  safety  and  controller  efficiency  for  all 
three  future  system  possibilities  relative  to  the  current  PVD/voice  system.  Newman  Keuls  post  hoc 
tests  on  the  means  indicated  that  both  Data  Link  implementations  would  produce  greater  system  safety 
than  the  existing  voice  system.  They  also  showed  that  the  ISSS  Data  Link  combination  would  yield 
greater  safety  than  the  PVD  Data  Link  system  (p<.01).  This  suggests  that  the  positive  impacts  of 
Data  Link  and  of  the  new  ISSS  on  safety  would  be  additive  in  their  effects. 

As  illustrated  in  the  figure,  the  largest  predicted  impact  of  the  ISSS  Data  Link  combination  was  its 
effect  on  the  ability  of  the  controller  to  efficiently  use  these  resources  to  expedite  the  flow  of  air 
traffic.  Statistical  testing  showed  that  while  both  the  addition  of  Data  Link  and  the  implementation  of 
the  ISSS  system  would  affect  controller  productivity,  the  combination  of  the  two  would  have  a 
positive,  interactive  effect  greater  than  the  sum  of  the  two  alone  (F  1,7  =  14.1,  p<.008), 

3.3.4  Summary  Evaluations  of  ISSS  Candidate  Data  Link  Service  Designs. 

A  second  group  of  ratings  completed  by  the  controllers  after  the  full  scale  simulation  runs  was  aimed 
at  providing  an  overall  summary  evaluation  of  the  candidate  ISSS  service  designs  as  implemented  for 
this  study.  For  each  of  the  services  the  controllers  were  asked  to  make  two  ratings.  The  first  of  these 
was  an  evaluation  of  the  operational  effectiveness  and  suitability  of  the  service.  For  this  rating, 
controllers  were  instructed  to  focus  on  the  extent  to  which  the  service  included  all  of  the  functions  and 
capabilities  needed  to  support  operational  requirements  in  a  field  en  route  ATC  setting. 

The  second  rating  was  an  evaluation  of  the  acceptability  of  the  design  to  controllers  and  their 
preference  for  its  features.  In  this  case,  the  subjects  were  asked  to  focus  on  usability  and  compatibility 
with  normal  controller  practice,  regardless  of  the  design's  effectiveness.  Subjects  were  explicitly 
instructed  that,  while  the  two  dimensions  of  effectiveness  and  acceptability  could  be  correlated,  it  is 
possible  for  a  design  to  contain  all  required  operational  features  and  be  difficult  to  use,  or  for  it  to  be 
highly  usable  but  fail  to  provide  all  features  needed  to  support  ATC  operations. 

Ratings  in  each  case  were  accomplished  by  first  indicating  whether  the  service  was  "not  operationally 
suitable"  or  "completely  unacceptable".  Alternatively,  if  the  service  met  at  least  some  operational 
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requirements,  or  was  at  least  minimally  acceptable,  they  rated  the  service  on  ordinal  7-point  scales 
ranging  firom  "minimally  effective"  (7),  to  "Ihghiy  effective"  (1),  and  "acceptable  but  not  preferred"(7) 
to  "highly  i«eferred"  (1). 


For  quantitative  analysis  purposes,  the  data  were  transformed  such  that  "not  operationally  suitable"  or 
"completely  unacceptable"  ratings  were  scored  as  1,  and  ratings  of  1  to  7  were  scored  as  8  through  2, 
respectively.  These  transformed  scores  for  each  variable  were  subjected  to  Friedman  Two-Way 
nonparametiic  analyses  of  variance  to  assess  the  significance  of  differences  in  ratings  among  the 
services. 

Statistically  significant  differences  among  the  services  were  detected  for  both  operational 
effectiveness/suitability  (Chi^  =  13.5,  p<.009)  and  for  controller  acceptance/preference  (Chi^  =  13.62, 
p<.008).  The  source  of  these  effects  can  be  identified  by  examining  table  2.  which  presents  the  median 
r^ings  for  the  transformed  data  (range  1  (lowest)  to  8  (highest)),  and  by  inspecting  figures  6  through 
10  which  present  the  raw  ratings  in  terms  of  frequency  distributions. 


TABLE  2.  MEDIAN  SUMMARY  RATINGS  OF  THE  CANDIDATE  ISSS  DATA  LINK 
SERVICE  DESIGNS 

TRANSFORMED  RATING  MEDIANS 


Range:  0  (not  effective/acceptable)  to 
8  (highly  effective/preferred) 


Ssmgg*. 

Operational  Effectiveness 
/Suitability 

Controller  Acceptance 
/&gfgr?ngs 

TOC 

7.5 

6.5 

AA 

7.0 

7.0 

MT 

6.5 

6.0 

CB 

5.5 

5.0 

IC 

3.5 

2.0 

♦  TOC  “  Transfer  of  Communication 
AA  "  Altitude  Assignment 
MT  ~  Menu  Text 
CB  "  Communications  Backup 
IC  “  Initial  Contact 


Transfer  of  Communication 

CandUaiB  ISSS  Saivica  Design  Ratings 


1  2  3  4  S  e  7  N 


OpeialioneiEHecIveness/Suilabfltty 
l=best;  7=wofst;  N=not  eSsctve 


No.  ofRespondems 


J _ \ _ I _ L 


Controller  Acceptartce/Preterence 
l=besl;  7=worst;  N=not  effective 


FIGURE  6.  SUMMARY  EVALUATIONS  OF  THE  CANDIDATE  TOC  DESIGN 


Altitude  Assignment 

CandkialB  ISSS  San/kia  Deeign  fiaUngs 
No.  of  Raapondents 


I  2  3  4  s  e  7  N 

Oporaional  EffecOveness/SuHabillty 
1=best:  7sN«yst  N=not  Elective 


No.  of  Respondents 


1  2  3  4  S  e  7  N 

ConMIer  Acceptance/Preference 
l^rbest  7=worst;  N=not  effective 


FIGURE  7.  SUMMARY  EVALUATIONS  OF  THE  CANDIDATE  AA  DESIGN 
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Menu  Text 

Candiaam  ISSS  Swvto*  Dasign  Ratings 
No.  ol  RasfionOenls 


1  2  3  4  5  e  7  N 

Openlion^  EttaONaness/SullablSfy 
1=bost:  7=worst:  Nsnot  elfacINe 


Controller  Acceplance/Preference 
1=best;  7sworst;  N=not  effective 


HGURE  8.  SUMMARY  EVALUATIONS  OF  THE  CANDIDATE  MT  DESIGN 
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Communications  Backup 

(^vtdidata  fSSS  Sentea  Design  Ratings 

No.  of  Resfiondants 


t  3  3  4  i  6  7  N 


OpafaMonaiEffaclivenasa/SuilabWIy 
1=bast;  7=wofst;  N=not  effecOva 


No.  of  Respondents 


Controller  AcceptarKa/Praference 
1=bast;  7=wo/st;  N=nol  affective 


HGURE  9.  SUMMARY  EVALUATIONS  OF  THE  CANDIDATE  CB  DESIGN 
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Initiai  Contact 

CanckiamiSSSSenfk»  Design  Ra1^ngs 
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5 
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3 
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7 

6 

5 

4 

3 

2 

1 

0 

ControNer  Acceptance/PrBhrwKe 
l=best;  7=worsf;  N=not  effocttve 

HGURE  10.  SUMMARY  EVALUATIONS  OF  THE  CANDIDATE  IC  DESIGN 


No,  of  Respondents 


1  2  3  4  S  6  7  N 


No,  of  Respondents 


1  2  3  4  S  $  7  N 

OpenMonal  EneONeness/Suitabmy 


As  shown  in  the  table,  TCXT  and  AA  were  highly  rated  on  both  evaluation  dimensions.  Neither  service 
design  received  a  "completely  unacceptable"  nor  "not  operationally  suitable”  rating.  Furthermore,  all 
of  the  controllers  rated  these  two  services  at  or  above  the  scale  midpoints  in  effectiveness  and 
acceptability. 

The  MT  function  received  tte  next  highest  ratings  on  both  dimensions,  with  all  ratings  at  or  above  the 
midpoint  of  tte  scales.  As  indicated  by  subject  comments  on  the  ratings,  the  somewhat  lower  scores 
than  those  obtained  for  TOC  and  AA  are  attributable  to  an  issue  in  the  application  of  MT  that  arose 
during  the  design  review.  For  the  present  study,  clearances  were  included  in  the  menu  to  permit 
subjects  to  control  leadings  and  speeds  during  test  runs.  This  was  accomplished  by  using  text  items  in 
the  menu.  While  altitude  items  in  the  menu  were  originally  designed  to  provide  FOB  status  and 
content  information,  text  items  had  been  designed  for  sending  non-critical,  non-control  messages. 
Consequently,  no  explicit  FOB  content  and  status  indication  or  status  list  content  indication  was 
designed  for  these  items.  When  using  the  text  items  in  the  menu  for  sending  clearances,  subjects  found 
the  lack  of  FDB  content  and  status  information  to  be  unacceptable,  and  recommended  that  any  control 
clearance  sent  by  MT  be  provided  with  this  feedback  data. 

The  CB  service  received  only  one  rating  below  the  scale  midpoint  for  operational  effectiveness,  but 
received  mixed  ratings  for  controller  acceptance,  with  raw  ratings  ranging  from  highly  preferred  (2)  to 
completely  unacceptable.  This  diversity  of  ratings  appears  to  reflect  differential  opinions  regarding  the 
Wv'*y  in  which  the  service  will  be  used  in  an  operational  implementation.  During  the  testing  many 
subjects  used  the  function  to  send  clearances  that  were  unavailable  on  the  menu.  This  practice 
concerned  some  subjects  because  of  the  potential  for  high  error  rates  when  using  free  text  entry.  The 
concerns  were  exacerbated  by  the  lack  of  FDB  displays  and  abbreviated  status  list  content  information 
in  the  CB  design. 

It  should  be  noted,  however,  that  the  design  of  the  candidate  service  was  based  on  an  assumed  set  of 
operational  procedures  which  would  limit  its  application.  CB  was  developed  for  non-critical,  non¬ 
control  messages,  except  in  the  case  of  lost  radio  communications.  Thus,  it  is  likely  that  the 
reasonably  high  operational  effectiveness  ratings  accompanied  by  mixed  acceptability  ratings  reflect 
this  concern  over  how  the  CB  function  will  be  used  rather  than  any  flaw  in  its  usability  or  operational 
suitability. 

The  lowest  overall  ratings  on  both  dimensions  were  received  by  the  candidate  IC  service  design. 

Three  of  the  eight  subject  controllers  indicated  that  the  design  was  "not  operationally  suitable,"  and 
only  one  rated  it  above  the  midpoint  on  the  operational  effectiveness/suitability  teale.  Four  of  the 
subjects  rated  IC  as  "completely  unacceptable”  to  controllers,  and  none  rated  it  above  the  midpoint  on 
the  acceptance/preference  scale. 

These  low  ratings  can  be  directly  attributed  to  a  flaw  in  this  service  that  was  identified  by  the 
controllers  during  the  design  review  phase  of  the  study.  As  described  in  section  3.2.4. 1,  the  IC  service 
used  an  automatic  check  of  the  downlinked  altitude  against  the  assigned  altitude  to  verify  concurrence. 
The  subjects  noted  that  there  are  several  conditions  in  operational  environments  where  the  data  base 
and  data  block  assigned  altitude  indication  do  not  correlate  with  the  legitimate  AA  of  the  aircraft. 


Because  of  these  situations,  the  candidate  service  design  would  display  an  unacceptably  large  number 
of  error  messages  to  the  controller. 


3.4  FINAL  DEBRIEFING. 

The  full  scale  simulation  phase  of  this  study  was  followed  by  a  final  debriefing  session.  This  debriefing 
revisited  the  designs  of  the  candidate  Data  Link  services  and  addressed  a  number  of  general  topics 
regarding  the  development  of  Data  Link  ATC  services  and  the  impact  of  implementing  these  services 
in  the  NAS.  Results  directly  concerned  with  design  changes  to  the  candidate  services  were  combined 
with  those  from  the  design  review  phase  of  the  study,  and  are  included  under  section  3.2  of  this 
document.  Additional  findings  from  the  debriefing  follow. 

3.4. 1  Comparison  of  Data  Link  in  the  Host/PVD  and  ISSS  . 

Discussion  of  the  relative  advantages  and  disadvantages  of  implementing  Data  Link  ATC  services  in 
the  ISSS  and  Host/PVD  systems  confirmed  the  individual  projective  rating  results.  Despite  the 
detailed  design  changes  recommended  during  the  study,  as  a  group,  the  controllers  preferred  Data 
Link  implemented  in  ISSS  over  the  PVD.  Factors  influencing  this  preference  included  a  greater  ability 
to  use  implied  commands  in  the  ISSS  designs,  the  availability  of  color  coding  for  alerts,  the  improved 
Data  Link  equipage/eligibility  symbology  in  the  FDB,  and  the  ability  to  use  a  single  command  to  upUnk 
a  messr^e  to  multiple  aircraft. 

The  controllers  also  noted  several  issues  that  must  be  resolved  to  insure  that  the  ISSS  Data  Link 
interface  will  be  operationally  suitable.  They  reiterated  that  the  current  ISSS  specification  does  not 
provide  for  some  of  the  command  input  requirements  that  enhance  the  efficiency  of  Data  Link 
keyboard  entry  tasks.  These  limitations  include  the  inability  to  automatically  delete  an  input  error 
message  by  retyping,  and  that  designation  of  multiple  aircraft  is  permitted  only  in  hand  off  messages. 

In  addition,  the  subjects  emphasized  the  importance  of  insuring  that  the  final  versions  of  the  keyboard, 
numeric  keypad  and  trackball  device  for  the  ISSS  common  console  be  selected  to  optimize  rapid  and 
accurate  operation. 

3.4.2  Future  Data  Link  Development  Requirements. 

Asked  to  recommend  high  priority  issues  in  future  development  of  ISSS  Data  Link  services,  the 
controllers  concurred  on  three  topics.  First,  they  repeated  their  recommendation  that  future  testing  be 
conducted  in  a  multiple  console  per  sector  configuration.  Such  a  configuration  is  expected  to  be  the 
norm  in  ISSS  operations,  and  will  provide  not  only  greater  realism  during  testing,  but  will  offer  the 
opportunity  to  explore  Data  Link  functions  that  can  be  performed  by  associate  ("D"  and  "T") 
controllers. 

Secondly,  the  group  indicated  that  it  will  be  imperative  to  design  a  fully  functional  capability  to 
efficiently  communicate  route  changes  using  Data  Link.  This  functionality  must  include  a  capability 
for  controllers  to  generate  a  new  route  in  real  time  and  send  it  to  an  aircraft.  It  also  must  have  a 
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capability  to  receive  a  downlinked  route  request  from  the  aircraft,  edit  the  request,  and  uplink  the 
modified  version  to  the  aircrew  for  direct  input  to  the  flight  management  system. 

A  final  lecotnmendation  concerned  the  process  by  which  the  results  of  developmental  studies  are 
carried  forward  to  guide  implementation  and  operational  testing  and  evaluation  (OT&E).  The 
controllers  were  aware  that,  in  the  current  system,  human  interface  requirements  derived  from 
developmental  research  are  documented  in  functional  specifications  that  are  used  to  guide 
implementation.  However,  the  functional  specifications  do  not  contain  the  rationale  upon  which  the 
characteristics  of  particular  design  feature  were  based,  nor  do  they  document  reconunended  controller 
procedures  for  safe  and  effective  use  of  the  design. 

It  was  noted  that  no  official  vehicle  exists  to  guarantee  that  this  information  is  provided  to 
implementers  and  OT&E  personnel  as  part  of  a  unified  package  of  informational  and  guidance 
materials  to  accompany  the  functional  design  specification.  The  controllers  noted  that  Data  Link 
communications  differ  from  voice  radio  communications  in  unique  ways,  and  that  they  broadly  impact 
strategies  for  performing  ATC  tasks.  Because  of  this,  they  argued  that  rationales  and  procedures 
generated  during  the  development  process  were  necessary  components  of  the  service  designs.  They 
recommended  that  approaches  be  explored  to  extract  this  information  from  study  reports  and  to 
embody  it  in  an  FAA  document  that  will  be  used  to  task  operational  evaluators  and  implementers. 

3.4.3  Effects  of  Implementing  Data  Link  in  En  Route  ATC. 

The  subjects  also  were  asked  to  comment  on  their  projective  ratings  of  the  impact  of  in^lementing 
Data  Link  ATC  services.  Corroborating  the  ratings,  the  group  did  not  see  Data  Link  as  a  technology 
that  would  significantly  affect  controller  workload  or  system  capacity. 

The  subjects  noted  that  Data  Link  introduces  additional  visual  monitoring  demands  to  the  controller's 
task.  However,  they  did  not  feel  that  workload  would  increase  with  an  optimized  display  interface  and 
with  the  ability  to  offload  some  communication  tasks  to  an  associate  controller.  The  controllers  also 
emphasized  that  absolute  changes  in  system  capacity  could  not  be  achieved  by  Data  Link,  since 
maximum  capacity  levels  are  determined  by  the  inherently  limited  capacity  of  airports  to  receive  and 
launch  aircraft. 

In  agreement  with  their  individual  projections,  a  majority  of  the  subjects  did  foresee  significant 
changes  in  system  safety  and  controller  efficiency  and  productivity  with  the  introduction  of  Data  Link 
ATC  services.  Predicted  safety  effects  were  attributed  to  the  reduction  in  common  communications 
errors  associated  with  the  voice  radio  system  discussed  earlier. 

Discussion  of  the  positive  impact  on  controller  efficiency  and  productivity  in  en  route  ATC  operations 
indicated  that  this  effect  would  be  a  direct  outcome  of  providing  a  second  communications  system 
operating  in  parallel  with  the  existing  voice  channel.  As  noted  above,  the  subjects  did  not  see  this 
increase  in  communications  capacity  as  directly  affecting  absolute  system  capacity.  However,  they 
were  confident  that  it  would  make  controllers  significantly  more  able  to  efficiently  use  available 
capacity. 
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A  specific  example  of  Data  Link  producing  an  increase  in  effective  capacity  is  the  situation  where  an 
en  route  airspace  sector  must  enforce  miles-in-trail  restrictions  on  airport  departures.  According  to 
tlw  controllers  participating  in  this  study,  the  resulting  aircraft  delays  are  not  introduced  because  of 
lack  of  available  airspace  or  runway  limitations  at  destination  airports.  Instead,  they  are  created  by  the 
inability  of  the  controller  to  communicate  effectively  with  all  of  the  aircraft  that  would  be  present  in 
the  sector  if  the  restriction  were  not  imposed. 

The  subjects  argued  that,  in  such  situations.  Data  Link  will  provide  the  additional  communications 
capacity  needed  to  prevent  such  costly  delays.  Hypothetically,  a  single  controller,  or  a  radar  controller 
and  an  associate  would  be  able  to  conduct  simultaneous  communications,  maintaining  traffic  flow 
levels  that  would  be  impossible  under  the  current  broadcast  voice  radio  system. 

3.4.4  MOPS  Compliant  IC  Procedures. 

As  an  adjunct  to  the  final  debriefing,  the  controllers  participated  in  a  structured  discussion  focused  on 
the  effects  of  altering  the  IC  service  to  become  compliant  with  the  Data  Link  MOPS.  The  IC  service 
which  was  tested  during  the  present  study  required  the  pilot  to  downlink  his  AA  in  conjunction  with 
th^  wilco  to  a  TOC  message.  As  Data  Link  eligibility  changes  to  the  receiving  controller  with  the 
wilco  receipt,  this  altitude  is  transferred  over  ground  systems  and  is  automatically  checked  against  the 
aircraft's  flight  plan.  An  error  message  is  presented  in  the  FDB  on  the  receiving  controller's  radar 
display  if  the  AA  message  fails  to  match  tte  smred  flight  data. 

The  recently  published  Data  Link  MOPS  dictates  that,  while  the  aircraft  may  dovmlink  its  AA  with  the 
TOC  wilco,  it  also  is  permitted  to  send  the  altitude  as  a  separate  message  directly  to  the  new 
controller.  Thus,  the  IC  service  will  require  redesign  to  accommodate  this  option. 

The  primary  issue  that  was  considered  during  the  discussion  was  the  potential  impact  of  time  delays  in 
the  modified  design.  Normally,  sending  the  AA  with  the  TOC  wilco  will  produce  a  nearly 
simultaneous  transfer  of  Data  Link  eligibility  and  altitude  check.  However,  a  separate  AA  downlink 
could  result  in  a  considerable  delay  between  the  receipt  of  eligibility  and  the  confirmation  that  the 
pilot's  intended  AA  conforms  with  the  flight  plan.  The  length  of  this  delay  would  depend  upon  a 
combination  of  realized  system  transmission  times,  the  design  of  the  flight  deck  Data  Link  interface, 
and  aircrew  procedures. 

After  viewing  a  simulation  of  this  alternative  procedure,  the  subject  group  unanimously  decided'  that 
excessive  time  delays  will  be  intolerable  in  the  IC  process.  The  stated  basis  for  this  opinion  was  that, 
before  controllers  can  begin  to  safely  issue  clearances  to  an  aircraft  entering  their  sector,  they  must 
have  reliable  knowledge  of  pilot  intent.  If  the  IC  message  is  delayed,  an  unsafe  situation  could  result 
where  aircraft  traverse  airspace  in  which  the  ATC  system  cannot  effectively  communicate  control 
messages. 
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The  results  of  this  study  support  the  following  conclusions  regarding:  (1)  initial  en  route  Data  Link  air 
traffic  control  (ATC)  services  for  the  Initial  Sector  Suite  System  (ISSS),  (2)  required  changes  to  the 
candidate  service  designs  and  the  prototype  simulation  system,  and  (3)  the  projected  impact  of  Data 
Link  on  ATC  system  performance. 

a.  The  findings  derived  from  the  full  scale  simulation  phase  of  the  study  indicate  that  Data  Link 
ATC  services  are  fully  compatible  with  the  ISSS.  Specifically,  the  results  predict  that  the  availability 
of  ISSS  Data  Link  will  significantly  expand  communications  capacity,  will  not  adversely  impact 
controller  workload,  and  will  enhance  system  safety.  Furthermore,  quantified  controller  judgments 
indicated  that  the  combination  of  ISSS  and  Data  Link  will  produce  a  significantly  greater  positive 
effect  on  controller  efficiency  and  productivity  than  the  implementation  of  either ,  ystem  alone. 

b.  Results  of  the  design  review  process  revealed  a  number  of  deficiencies  in  the  candidate 
versions  of  the  initial  ISSS  Data  Link  ATC  service  designs,  and  generated  design  changes  to  remediate 
these  deficiencies.  Requirements  for  modifications  and  enhancements  to  the  candidate  service  designs 
are  fully  described  in  the  results,  and  key  changes  are  listed  in  the  recommendations  section  of  this 
report. 

c.  The  participating  controllers  favorably  evaluated  the  ISSS  prototype  simulation  system  as  a 
test  bed  for  continued  Data  Link  service  development.  Suggested  improvements  to  the  system 
included  the  addition  of  a  limited  number  of  additional  ISSS  views  and  command  functions, 
enhancement  of  the  simulated  aircraft  models,  and  the  expansion  of  the  system  to  multiple  common 
console  suites. 


The  following  recommendations  for  future  actions  toward  the  development  of  Data  Link  air  traffic 
control  (ATC)  services  for  implementation  on  the  Initial  Sector  Suite  System  (ISSS)  are  derived  from 
the  results  and  conclusions  of  the  present  research. 

a.  This  preliminary  design  development  study  produced  positive  controller  assessments  of  the 
impact  of  Data  Link  in  the  domestic  en  route  ATC  environment,  and  evidence  that  these  effects  will  be 
enhanced  by  the  improved  controller  interface  associated  with  the  ISSS.  Therefore,  it  is  recommended 
that  the  Federal  Aviation  Administration  (FAA)  should  pursue  continued  development  of  Data  Link 
ATC  services  for  the  ISSS,  and  that  it  should  integrate  these  services  with  the  ISSS  implementation 
schedule  at  the  earliest  feasible  opportunity. 

b.  Each  of  the  modifications  and  enhancements  to  the  candidate  ISSS  Data  Link  ATC  service 
designs  recorded  in  the  results  section  of  this  report  are  recommended  for  implementation  and 
subsequent  controller  testing  in  the  ISSS  prototype  simulation  system.  These  recommendations 
include,  but  are  not  limited  to,  the  following: 


1 .  Full  data  block  (FDB)  message  status  and  content  displays  must  be  developed  for  all 
uplink  messages  involving  ATC  instructions. 

2.  Specific  speed  and  heading  control  services  should  be  developed  based  upon  the  model 
provided  by  the  existing  AA  services.  The  features  of  these  services  should  include  FDB  status  and 
content  displays,  manual  entry  and  menu  selection  methods  for  message  composition  and  uplink,  and 
consistent  alert  displays. 

3.  Logic  checks  requiring  deliberate  override  command  inputs  should  be  added  to  prevent 
inadvertent  deletion  of  open  Data  Link  transactions. 

4.  The  initial  contact  (IC)  service  must  be  modified  to  prevent  a  high  incidence  of  false 
alarm  alerts  in  situations  where  the  aircraft's  true  assigned  altitude  (A>V)  is  not  reflected  in  the 
controller’s  FDB  or  the  National  Airspace  System  (NAS)  data  base. 

5.  A  capability  should  be  developed  and  tested  to  display  an  historical  record  of  Data  Link 
transactions  that  have  been  successfully  completed  with  an  aircraft. 

c.  In  order  to  facilitate  Data  Link  integraticm,  recommendations  should  be  forwarded  to  the 
ISSS  program  to  modify  existing  command  input  specifications.  The  specification  requiring  a 
keyboard  entry  to  clear  entry  error  messages  should  be  modified  to  permit  automatic  deletion  of  the 
error  message  upon  retyping.  The  capability  to  specify  multiple  flight  identification  (FLID  )  entries 
with  a  single  hand  off  entry  should  be  extended  to  all  Data  Link  messages. 

d.  In  response  to  the  current  Data  Link  Minimal  Operating  Performance  Specification 
(MOPS)  regarding  options  for  downlinking  the  IC  message,  the  controller  participants  recommend 
that  the  altitude  be  appended  to  the  TOC  response.  To  maintain  system  safety,  any  other  option 
should  result  in  time  delays  for  receipt  and  evaluation  of  the  altitude  which  are  no  greater  than  those 
associated  with  the  recommended  procedure. 

e.  Future  developments  of  Data  Link  ATC  services  for  the  ISSS  should  include  testing  with 
multiple  console  per  sector  suites.  They  should  also  include  the  evaluation  of  distributing  Data  Link 
communications  functions  among  the  radar  and  associate  controllers.  Finally,  testing  should  explore 
methods  for  utilizing  the  fourth  line  of  the  ISSS  FDB  and  the  electronic  flight  strip  displays  as  Data 
Link  interaction  tools. 

f.  In  order  to  preserve  and  effectively  apply  the  full  range  of  findings  obtained  in  Data  Link 
design  development  studies,  it  is  recommended  that  an  official  FAA  documentation  vehicle  be  created 
to  record  design  rationale  information  and  procedural  recommendations.  This  publication  should 
accompany  the  functional  design  specifications  for  Data  Link  ATC  services  as  additional  guidance  for 
development  of  operational  software,  operational  test  and  evaluation,  and  implementation. 
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APPENDIX  A 

ISSS  DATA  LINK  CANDIDATE  SERVICE  DESIGN  DESCRIPTIONS 


NOTES  ON  CONVENTIONS  USED  IN  DESCRIPTIONS 


In  the  following  ISSS  common  console  service  descriptions: 


-  Two  trackball  keys  are  used.  Trackball  ENTER  (middle  key)  is 
used  to  complete  a  command  sequence.  Trackball  SELECT  (left 
key)  is  used  to  identify  an  item  for  modification  in  the 
message  composition  (MC)  view  and  to  identify  lists  for  moving 
them  on  tl^  display. 


-  Data  as  shown  in  a  display  or  entered  on  the  keyboard  are 

presented  in  quotation  marks.  When  spaces  are  required,  they  are  included  within  the 
quotation  marks.  The  quotation  marks  are  not  part  of  the  display  or  entry. 


-  All  spaces  included  within  quotation  maiks  for  keyboard  entries 
are  mandatory.  For  example,  "DL  S  "  should  be  interpreted  as 
typing  DL  followed  by  a  space,  and  S  followed  by  a  space. 

-  FLID  refers  to  any  NAS  command  for  identifying  a  flight 
including: 

.  The  Aircraft  Identification  Call  Sign  (AID) 

.  The  Computer  Identification  Number  (CID) 

.  The  Beacon  Code 

.  Positioning  the  trackball  cursor  over  the  data 
block  and  pressing  trackball  ENTER 
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DATA  LINK  FULL  DATA  BLOCK  DISPLAYS  AND  STATUS  LIST 


-  Function 

The  Full  Data  Block  (FDB)  provides  unique  graphic  characters  which  indicate  that  an  aircraft  is 
equipped  to  receive  Data  Link  messages,  and  whether  the  observing  control  position  is  eligible  to 
uplink  messages  to  the  aircraft.  The  FDB  also  provides  information  about  the  status  of  an 
ongoing  Data  Link  transaction. 

The  status  list  is  an  ISSS  view  which  contains  information  about  the  content  and  current  status  of 
ongoing  Data  Link  transactions. 


-  Full  Data  Block  Equipage  and  Eligibility  Indicators 

Data  Link  equipage  and  eligibility  are  indicated  by  graphic  characters  located  in  the  first  position 
of  the  first  line  of  the  FDB.  No  special  character  in  this  position  identifies  an  aircraft  that  is  not 
ctqiable  of  communicating  via  Data  Link.  An  open  diamond  (  )  indicates  that  the  aircraft  is  Data 
Link  equipped,  but  that  the  viewing  sector  position  is  ineligible  to  communicate  with  it.  A  filled 
diamond  (  )  indicates  that  the  aircraft  is  equipped  and  that  the  viewing  sector  is  eligible. 


-  Status  List  Line  Content 

The  status  list  is  identified  by  "DLSL"  displayed  in  the  header  area  of  the  view.  Each  line  of  the 
list  contains  information  about  one  ongoing  transaction.  A  line  has  four  data  fields  displaying  1) 
the  aircraft  identification,  2)  a  two-letter  abbreviation  for  the  Data  Link  service  or  function,  3)  up 
to  eight  characters  indicating  the  content  of  the  uplinked  message,  and  4)  a  three-letter 
abbreviation  for  the  status  of  the  transaction.  For  example,  "UA 123  AA  300  SNT"  would 
indicate  that  the  controller  had  uplinked  an  altitucte  assignment  of  30,000  feet  to  UA123  and  that 
the  message  is  in  the  sent  status. 

-  Status  List  Abbreviations  for  Data  Link  Services 

The  second  field  of  a  status  line  presents  one  the  following  two-character  abbreviations  to  indicate 
the  type  of  message  in  progress: 

’TC"  -  Transfer  of  Communication 

"AA"  -  Altitude  Assignment 
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"lA"  -  Interim  Altitude 


"MT"  -  Menu  Text 

"FT"  -  Communication  Backup  (Free  Text) 


-  Status  List  Abbreviations  of  Transaction  Status 

The  fourth  field  of  a  status  line  presents  the  following  three-character  abbreviations  to  indicate  the 

current  status  of  the  transaction: 

"SNT"  -  Sent  -  A  controller  input  or  system  event  has 
initiated  the  uplink 

"HLD"  -  Held  -  A  message  containing  the  radio  frequency  of  a 
new  airspace  sector  which  the  aircraft  will  enter  has 
been  prepared  and  is  ready  for  uplink  wtK;n  the  sending 
controller  makes  an  appropriate  input.  "HLD"  is 
displayed  in  yellow  to  indicate  a  routine  required 
controller  action. 

"WIL"  -  Wilco  -  The  system  has  received  a  downlink  from  the 
flight  deck  indicating  that  the  pilot  has  i«:eived  the 
the  uplinked  message  and  intends  to  comply  with  the 
coimnand  or  clearance. 

"UNB"  -  Unable  -  The  system  has  received  a  downlink  from  the 
flight  deck  indicating  that  the  pilot  has  r»;eived  the 
the  uplinked  message,  but  is  unable  to  comply  with  the 
conunand  or  clearance.  "UNB"  is  displayed  in  yellow  to  alert 
the  controller. 

"STB"  -  Standby  -  The  system  has  received  a  downlink  from  the 
flight  deck  indicating  that  the  pilot  has  received  the 
the  uplinked  message,  but  requires  additional  time  to 
evaluate  the  message  and  send  a  wilco  or  unable 
response.  STB"  is  displayed  in  yellow  to  alert  the 
controller. 

"TIM"  -  Time  Out  -  A  timer  initiated  when  the  uplinked  message 
was  sent  has  expired.  For  testing  purposes,  this 
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adaptable  time  parameter  is  set  to  40  seconds.  The 
time  out  message  is  an  indication  to  the  controller  of 
an  unusually  lengthy  delay  for  receipt  of  a  response 
from  the  aircraft.  "TIM"  is  displayed  in  yellow  to 
alert  the  controller. 


-  Full  Data  Block  Indications  for  Data  Link  Services  and 
Transaction  Status 

FDB  status  and  content  indicators  ate  correlated  with  the  status  list  indicators,  but  vary  depending 
u^n  the  service  involved. 

Hiey  are  described  in  detail  under  succeeding  sections  devoted  to  each  service. 

-  Inputs  to  Move  the  Status  List 

The  status  list  view  can  be  moved  to  any  position  on  the  display  by  typing  "M",  positioning  the 
cursor  in  the  header  area  of  the  status  list  and  pressing  the  trackball  SELECT  key,  repositioning 
the  list,  and  pressing  the  trackball  ENTER  key. 


-  Inputs  to  Suppress  or  Retrieve  the  Status  List 

The  status  list  view  can  be  suppressed  by  typing  "SU",  positioning  the  trackball  cursor  in  the 
header  area  of  the  status  list,  and  pressing  the  trackball  ENTER  key.  An  icon  located  over  the 
upper  left  comer  of  tte  suppressed  list  indicates  its  position.  Typing  "SU",  positioning  the  cursor 
over  the  icon  and  pressing  the  trackball  ENTER  key  will  unsuppress  (display)  the  status  list. 

ENTRY  ERROR  MESSAGES 

In  addition  to  other  ISSS  controller  input  error  messages,  the  following  Data  Link  error  messages 
may  a{^)ear  in  the  Messi^e  Composition  (MQ  view: 


-  "NOT  DL  ELIGIBLE  FOR  SECTOR" 

This  message  will  appear  if  the  controller  attempts  to  send  a  Data  Link  message  to  an  equipped 
aircraft  with  which  the  controller  is  ineligible  for  communication  (open  diamond  shown  in  first 
position  of  first  FDB  line  as  displayed  at  the  controller's  sector). 
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-  "NO  DATA  LINK 


This  message  will  appear  if  the  controller  attempts  to  send  a  Data  Link  n^ssage  to  a  non- 
equipped  aircraft  (no  symbol  shown  in  first  position  of  first  FDB  line  as  displayed  at  the 
controller's  sector). 


-  "MAX  NO.  OF  AA  EXCEEDED" 

TC 

This  message  will  appear  if  the  controller  attempts  to  send  a  second  altitude  (AA)  or  transfer  of 
communication  (TC)  message  to  an  aircraft  that  currently  has  one  of  the  same  type  of  transaction 
open. 


-  "DATA  LINK  NOT  ENABLED" 

This  message  will  appear  if  the  controller  attempts  to  send  an  uplink  when  Data  Link  processing  is 
turned  off  for  the  sector. 


-  "TRANSACTION  ACTIVE  FOR  SERVICE" 

This  message  will  appear  if,  while  a  Data  Link  transaction  remains  open,  the  controller  attenq>ts 
to:  1)  transfer  Data  Link  eligibility  to  another  sector,  2)  handoff  an  aircraft,  3)  amend  an  altitude 
or  4)  uplink  a  menu  text  altitude  message.  This  message  also  will  be  returned  if  the  controller 
attempts  to  send  a  backup  communication  (FT)  message  when  three  other  backup  transactions  to 
that  aircraft  are  open. 


-  "INVALID  STATUS  FOR  DELETION" 

This  message  will  appear  if  the  controller  attempts  to  delete  a  Data  Link  transaction  that  has  a 
status  other  than,  HELD,  UNABLE,  or  TIME  OUT. 


-  "MT  NO  VALID  DATA" 

This  message  will  appear  if  the  controller  attempts  to  change  the  content  of  a  menu  text  message 
which  does  not  have  a  variable  altitude  value  field. 
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TRANSFER  OF  COMMUNICATION 


-  Function 

Hk  Data  Link  transfer  of  communication  message  is  automatically  prepared  when  tiK  receiving 
controller  accepts  a  sector  handoff  for  an  equipped  aircraft.  The  sending  controller  has  the  option 
to  send  the  new  frequency  automatically  when  the  handoff  is  accepted,  or  to  send  the  message 
manually  at  a  later  time. 


-  Inputs  to  Set  the  Transfer  of  Communication  Mode 

Transfer  of  communication  can  be  set  to  the  automatic  mode  by  typing  "DP  A".  The  manual 
mode  is  set  by  typing  "DP  M". 

If  the  USER  DFBL  soft  ftmction  set  has  been  selected,  pressing  F8  will  substitute  for  typing  "DP 
A"  and  pressing  F9  will  substitute  for  typing  "DP  M". 


'  Manual  and  Automatic  Send  Inputs 

When  in  the  automatic  mode,  the  transfer  of  communication  message  will  be  uplinked  with  no 
additional  action  by  the  sending  controller  when  the  receiving  sector  accepts  the  handoff. 

When  in  the  manual  mode,  acceptance  of  the  handoff  will  place  the  prepared  message  in  a  held 
status.  The  message  is  sent  by  the  controller  by  slewing  to  the  ^propriate  line  in  the  status  list 
and  pressing  the  trackball  ENTER. 


-  Status  List  and  Full  Data  Block  Displays  on  Transfer  of 
Communication 

The  status  list  entry  for  a  transfer  of  communication  transaction  presents  the  AID,  the  two  letter 
abbrevi^on  'TC",  the  receiving  sector's  frequency,  and  the  current  transaction  status  message. 
When  in  a  manual  morfe,  the  "HLD"  status  message  is  displayed  in  yellow  until  the  controller 
completes  the  slew  action  to  send  the  message.  In  the  automatic  mode,  the  status  line  appears  in 
the  "SNT"  state  immediately  after  acceptance  of  the  handoff. 

In  either  mode  of  operation,  when  the  transfer  of  communication  message  is  sent,  an  up-arrow 
symbol  replaces  the  Data  Link  equipage/eligibility  indicator  in  the  first  position  of  the  first  line  of 
the  PDB  that  is  displayed  to  the  sending  and  receiving  sectors.  When  the  wilco  is  received  fiom 
the  flight  deck,  the  up-arrow  is  replaced  by  the  filled  diamond  in  the  receiving  sector  and  by  the 
open  diamond  in  the  sending  sector. 
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-  Unable  and  Time  Out  Displays  for  Transfer  of  Conununication 
and  Controller  Responses. 

If  the  flight  deck  responds  to  a  transfer  of  communication  message  with  an  unable,  "UNB"  is 
displayed  in  yellow  in  the  status  field  of  the  status  list.  If  the  flight  deck  fails  to  downlink  a 
response  within  40  seconds,  "TIM"  is  displayed  in  yellow  in  the  status  field. 


The  unable  or  time  out  conditions  also  will  cause  the  up-arrow  in  the  first  position  of  the  first  line 
of  the  sending  controller's  FDB  to  revert  to  the  filled  diamond  symbol  indicating  that  Data  Link 
eligibility  remains  at  the  sending  sector.  However,  the  filled  diamond  will  be  yellow  rather  than 
white  to  alert  the  controller. 

The  controller  can  close  the  transaction  and  delete  all  "UNB"  or  "TIM"  indicators  by  typing  "D" 
positioning  the  cursor  over  the  status  list  entry,  and  pressing  the  trackball  ENTER  key. 
Alternatively,  the  controller  may  type  "D  TC  "  and  the  FLID;  or  "D ",  the  sequential  number  of 
the  line  in  the  status  list  (counting  from  the  tqj  of  the  list),  and "  V/DLSL".  Thus,  "D  3  V/DLSi. 
would  delete  the  transaction  on  the  third  line  of  the  list. 


-  Sending  an  Automatic  Transfer  of  Communication  When  in  Manual 
Mode 

While  working  in  the  manual  mode,  the  controller  can  selectively  choose  to  send  the  message 
automatically  to  individual  aircraft  by  adding  a  single  keystroke  to  the  normal  sequence  used  to 
offer  a  handoff.  The  transfer  of  communication  message  will  be  sent  automatically  upon  bandoff 
acceptance  if  the  controller  offers  the  handoff  by  typing  "HO ",  the  two  digit  receiving  sector 
number, "  S  ",  and  one  or  more  FLIDs  separated  by  spaces  (e.g.  "HO  22  S  US435).  Note: "HO"  is 
an  optional  input.  Adding  the  "S"  to  a  single  handoff  command  will  not  affect  other  subsequent 
aircraft  handoffs,  and  the  default  mode  will  remain  manual. 


-  Forcing  Data  Link  Eligibility  to  a  Sector 

A  sector  that  has  Data  Link  eligibility  can  transfer  it  to  a  new  sector  without  completion  of  a 
handoff  by  typing  "DL  "  the  two  digit  receiving  sector  number  followed  by  a  space,  and  one  or 
more  FLIDs  separated  by  spaces  (e.g.  "DL  22  UA765"). 

To  simultaneously  force  eligibility  and  send  the  new  sector  frequency  to  the  flight  deck,  insert "  S 
"  after  the  sector  number  (e.g.  "DL  22  S  UA765"). 
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In  the  above  commands,  if  the  USER  DFBL  soft  function  set  has  been  selected,  pressing  FI  will 
substitute  for  typing  "DL". 


•  "Stealing"  Data  Link  Eligibility  from  a  Sector 

Data  Link  eligibility  can  be  acquired  from  another  sector  in  the  absence  of  a  completed  handoff  by 
typing  "DL  /OK "  followed  by  one  or  more  FLIDs  separated  by  spaces. 

To  simultaneously  acquire  eligibility  and  send  your  sector  frequency  to  the  flight  deck,  insert "  S  " 
after  the  /OK  (e.g. 

"DL/OKSUS221". 

In  either  command,  if  the  USER  DFBL  soft  function  set  is  selected  pressing  F2  will  substitute  for 
typing  "DL/OK". 


-  "Stealing"  Data  Link  Eligibility  from  a  Sector  and  Forcing 
to  Another  Sector 

Sector  A  can  acquire  eligibility  from  sector  B  and  force  it  to  sector  C  by  typing  "DL  /OK "  the 
two  digit  number  of  sector  C,  and  one  or  more  FLIDs  separated  by  spaces.  Thus,  if  the  controller 
at  sector  A  typed  "DL  /OK  21  AA534",  AA534  Data  Link  eligibility  would  be  taken  from  sector 
B  and  forced  to  sector  21  (sector  C). 

To  simultaneously  complete  the  transfer  and  send  sector  Cs  frequency  to  the  flight  deck,  insert " 

S  "  after  the  sector  number  (e.g.  "DL  /OK  21  S  AA534"). 

In  either  command,  if  the  USER  DFBL  soft  function  set  has  been  selected,  pressing  F2  will 
substitute  for  typing  "DL  /OK". 


ALTITUDE  ASSIGNMENT  -  MANUAL  ENTRY 


-  Function 

This  service  permits  the  controller  to  uplink  an  altitude  assignment  or  an  interim  altitude  by 
manually  entering  a  three  digit  altitude  value  (hundreds  of  feet).  A  message  that  receives  a  wilco 
downlink  from  the  flight  deck  automatically  updates  the  the  NAS  database  and/or  the  FDB,  as 
appropriate. 
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-  Inputs  to  Send  an  Altitude  Assignment 


To  update  the  NAS  database  when  an  altitude  is  assigned  by  voice  radio  the  ISSS  Amend 
command  is  used.  This  is  achieved  by  typing  "AM  ALT ",  three  digits  indicating  the  altitude  in 
hundreds  of  feet,  and  a  space  followed  by  the  FLID.  The  "AM  ALT  "  portion  of  the  command  is 
optional. 

To  update  the  system  jjjd  send  the  message  by  Data  Link,  an  "S"  is  inserted  between  the  altitude 
value  and  the  FLID 

(e.g.  "AM  ALT  300  S  UA123"  keyboard  ENTER  or  "300  S"  slew  to  aircraft  FDB,  trackball 
ENTER) 


-  Full  Data  Block  and  Status  List  Displays  on  Altitude  Uplink 

When  the  assigned  altitude  send  command  is  entered,  the  new  altitude  value  followed  by  an  "S" 
appears  in  the  first  four  positions  of  the  second  line  of  the  FDB.  This  timeshaies  with  the  display 
of  the  previous  assigned  altitude  and  conformance  indicator. 

Upon  receipt  of  a  wilco  response  from  the  flight  de  'k,  the  "S"  is  replaced  by  a  "W".  The 
timesharing  continues  for  six  seconds,  after  which  the  new  assigned  altitude  is  shown  with  the 
appropriate  conformance  indicator. 

During  the  transaction,  the  status  list  displays  the  AID,  the  "AA"  message  type  abbreviation,  the 
altitude  value  and  the  current  status  abbreviation.  Upon  receipt  of  a  wilco,  "WIL"  is  displayed  for 
six  seconds,  after  which  the  entire  status  list  line  is  automatically  deleted. 


-  Inputs  to  Send  an  Interim  Altitude 

To  update  the  data  block  when  an  interim  altitude  sent  by  voice  radio  the  ISSS  Amend  command 
is  used.  This  is  achieved  by  typing  "AM  T ",  three  digits  indicating  the  altitude  in  hundreds  of 
feet,  and  a  space  followed  by  the  FLID.  The  "AM"  portion  of  the  command  is  optional. 

♦  To  update  the  FDB  aM  send  the  message  by  Data  Link,  an  "S"  is  inserted  between  the  altitude 

value  and  the  FLID 

(e.g.  "AM  T  1(X)  S  UA123"  keyboard  ENTER  or  "T  100  S"  slew  to  aircraft  FDB,  trackball 
ENTER) 
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-  Full  Data  Block  and  Status  List  Displays  on  Interim  Altitude 
Uplink 


When  the  interim  altitude  send  command  is  entered,  the  interim  altitude  value  followed  by  an  "S" 
a[^)ears  in  the  first  two  fields  of  the  second  line  of  the  FDB.  This  timeshaies  with  the  display  ot 
the  current  assigned  altitude  and  conformance  indicator.  Upon  receipt  of  a  wilco  response  from 
the  flight  deck,  the  "S"  is  replaced  by  a  "W".  The  timesharing  continues  for  six  seconds,  after 
which  the  accepted  interim  altitude  is  shown  with  the  normal  "T"  conformance  indicator. 

During  the  transaction,  the  status  list  displays  the  AID,  the  "LA"  message  type  abbreviation,  the 
interim  altitude  value  and  the  current  status  abbreviation.  Upon  receipt  of  a  wilco,  "WIL"  is 
displayed  for  six  seconds,  after  which  the  entire  status  list  line  is  automatically  deleted. 


-  Unable  and  Time  Out  Displays  for  Assigned  and  Interim  Altitudes 
and  Controller  Responses. 

If  the  flight  deck  respond  to  an  altitude  clearance  with  an  unable,  "UNB"  is  displayed  in  yellow  in 
the  status  field  of  the  status  list.  If  the  flight  deck  fails  to  downlink  a  response  within  40  seconds, 
"TIM"  is  displayed  in  yellow  in  the  status  field.  In  the  FDB,  "UNB"  or  "TIM"  is  displayed  in 
yellow  in  the  last  three  positions  of  the  second  line  to  indicate  these  failure  conditions. 

In  either  case,  the  controller  can  close  the  transaction  and  delete  all  "UNB"  or  "TIM"  indicators 
by  typing  "D"  positioning  the  cursor  over  the  status  list  entry,  and  pressing  the  trackball  ENTER 
key.  Alternatively,  the  controller  may  type  "D  ","AA "  or  "lA  ",  and  the  FLID;  cm-  "D  ",  the 
sequential  number  of  the  line  in  the  status  list  (counting  from  the  top  of  the  list),  and "  V/DLSL". 
Thus,  "D  3  V/DLSL"  would  delete  the  transaction  on  the  third  line  of  the  list. 


INITIAL  CONTACT 

-  Function 

This  service  substitutes  the  initial  radio  call  from  the  flight  deck  after  a  transfer  of  communication 
with  a  downlink  report  of  assigned  altitude.  Under  normal  conditions,  the  initial  contact 
procedure  is  automatic  and  transparent,  and  requires  no  controller  interaction. 

-  Initial  Contact  Procedure 

An  altitude  request  message  is  automatically  appended  to  the  radio  frequency  assignment  message 
that  is  uplinked  during  transfer  of  communication.  The  flight  deck  responds  to  the  transfer  of 


communication  uplink  by  downlinking  a  wilco  along  with  a  report  of  assigned  altitude  to  the 
sending  controller. 

Receipt  of  the  wilco  response  transfers  Data  Link  eligibility  to  the  receiving  sector.  In  addition, 
the  reported  assigned  altitude  is  automatically  checked  against  the  aircraft's  assigned  altitude 
recorded  in  the  NAS  data  base.  If  the  aircraft’s  reported  assigned  altitude  matches  the  data  base 
value,  nothing  is  displayed  at  the  sending  or  receiving  sectors,  and  no  additional  controller  action 
is  required. 

-  Flight  Deck  Failure  to  Append  Reported  Altitude 

If  the  flight  crew  fails  to  append  the  altitude  report  to  the  transfer  of  communication  wilco,  a  no 
altitude  ("NALT")  message  is  displayed  in  the  first  four  positions  of  the  second  line  of  the  FDB  at 
both  the  sending  and  receiving  controllers'  display.  "NALT"  is  displayed  in  yellow  to  alert  the 
controllers. 


The  Data  Link  eligible  receiving  controller  with  track  control  may  respond  by  contacting  the  flight 
deck  via  voice  radio,  and  can  clear  the  "NALT"  display  by  slewing  to  the  FDB,  or  by  updating  the 
aircraft's  assigned  or  interim  altitude,  with  or  without  an  uplink  to  the  flight  deck. 

-  Discrepancy  Between  Reported  and  Flight  Plan  Assigned  Altitudes 

If  the  reported  assigned  altitude  fails  to  match  the  assigned  altitude  contained  in  the  NAS  data 
base,  the  downlinked  value  and  the  data  base  values  followed  by  "E"  timeshare  in  the  first  four 
positions  of  the  second  line  of  the  FDB.  This  display  is  presented  in  yellow  to  alert  the 
controllers. 

The  Data  Link  eligible  receiving  controller  with  track  control  may  respond  by  contacting  the  flight 
deck  via  voice  radio,  and  can  clear  the  error  display  by  slewing  to  the  FDB,  or  by  updating  the 
aircraft's  assigned  or  interim  altitude,  with  or  without  an  uplink  to  the  flight  deck. 


MENU  TEXT 

-  Function 

The  Menu  Text  function  permits  the  controller  to  uplink  frequently  used  messages  by  selecting 
them  from  a  predefined  menu  view.  Currently,  these  messages  include  altitude  assignments. 


interim  altitudes  with  fix  crossing  restrictions,  and  text  messages.  Menus  can  be  tailored  to  meet 
the  specific  requirements  of  individual  airspace  sectors. 


-  Menu  Format 

The  menu  is  an  ISSS  view  identified  by  "DLMT"  in  the  header  area.  Each  line  of  the  menu 
contains  one  message  preceded  by  an  identifying  letter  used  to  select  the  message.  Altitude 
messages  are  preceded  by  QZ  or  QQ  to  indicate  whether  the  clearance  is  an  altitude  assignment  or 
an  interim  altitude.  Some  sample  messages  are  shown  below: 

A  QZ  CLIMB  AND  MAINTAIN  FL  230 
B  QQ  CROSS  BUZZY  @  110 
C  QZ  DESCEND  AND  MAINTAIN  FL  100 
D  CALL  COMPANY 


-  Inputs  to  Send  a  Menu  Text  Message 


To  send  a  menu  text  message  (and  update  the  NAS  data  base/FDB  when  appropriate)  type  "DL " 
the  menu  item  identifier  followed  by  a  space,  one  or  more  FLIDs  and  ENTER.  The  message  can 
be  sent  to  multiple  aircraft  by  adding  additional  FLIDs  prior  to  pressing  ENTER  (e.g.  "DL  D 
AA123  UA321"). 

To  send  a  message  using  only  the  trackball,  slew  to  the  desired  menu  item  and  press  the  trackball 
ENTER  key,  and  then  SLEW  to  the  FDB  and  press  the  trackball  ENTER  key. 


-  Full -Data  Block  and  Status  List  Displays  on  Menu  Text  Uplink 

If  the  uplinked  menu  item  is  an  altitude  assignment  or  an  interim  altitude,  the  FDB  content  and 
status  displays  will  be  identical  to  those  described  for  manually  entered  altitude  clearances.  No 
FDB  display  is  provided  if  the  menu  item  is  a  text  message. 

For  all  messages  sent  from  the  menu,  the  status  list  will  display  the  AID  followed  by  "MT",  the 
menu  item  identifier,  and  the  current  status  of  the  transaction  (e.g.  "AA231  MT  A  SNT").  The 
actual  content  of  the  message  can  be  reviewed  by  referring  to  the  indicated  item  identifier  in  the 
menu. 


-  Unable  and  Time  Out  Displays  for  Menu  Text  and  Controller 
Responses. 

FDB  and  status  list  displays  for  these  failure  conditions  for  menu  text  altitude  messages  are 
identical  to  those  provided  for  manually  entered  assigned  and  interim  altitudes.  If  the  flight  deck 
responds  to  a  menu  text  altitude  clearance  with  an  unable,  "UNB"  is  displayed  in  yellow  in  the 
status  field  of  the  status  list.  If  the  flight  deck  fails  to  downlink  a  response  within  40  seconds, 
"TIM"  is  displayed  in  yellow  in  the  status  field.  In  the  FDB,  "UNB"  or  "TIM"  is  displayed  in 
yellow  in  the  last  three  positions  of  the  second  line  to  indicate  these  failure  conditions. 

Unable  and  time  out  displays  for  text  messages  in  the  menu  are  presented  only  in  the  status  list.  If 
the  flight  deck  responds  to  a  communications  back  up  message  with  an  unable,  "UNB"  is 
displayed  in  yellow  in  the  status  field  of  the  status  list.  If  the  flight  deck  fails  to  downlink  a 
response  within  40  seconds,  "TIM"  is  displayed  in  yellow  in  the  status  field. 

The  controller  can  close  any  menu  text  transaction  and  delete  all  "UNB"  or  "TIM"  indicators  by 
typing  "D"  positioning  the  cursor  over  the  status  list  entry,  and  pressing  the  trackball  ENTER  key. 
Alternatively,  the  controller  may  type  "D ",  the  sequential  number  of  the  line  in  the  status  list 
(counting  from  the  top  of  the  list),  and "  V/DLSL".  Thus,  "D  3  V/DLSL"  would  delete  the 
transaction  on  the  third  line  of  the  list. 


-  Special  Menu  Text  Items  (R  and  Z) 

Two  menu  item  identifiers  are  reserved  for  special  altitude  uplinks.  Selecting  item  "R"  when 
included  in  a  menu  will  uplink  the  aircraft's  requested  altitude.  Selecting  item  "Z"  when  included 
in  a  menu  will  uplink  the  aircraft's  assigned  altitude. 

(note:  these  items  are  not  supported  in  the  current  simulation) 

-  Modifying  Menu  Text  Altitude  Item  Content 

A  complete  menu  build  function  will  be  used  by  supervisory  personnel  to  create  sector-tailored 
menus.  However,  it  is  expected  that  controllers  will  have  some  latitude  to  modify  menu  content 
on  an  as-needed  basis. 

To  change  the  altitude  value  in  an  existing  menu  item,  type  "DP  MC  "  the  menu  item  identifier 
followed  by  a  space  and  the  new  altitude  value  (e.g.  DP  MC  A  1(X)).  This  action  will  change  the 
displayed  data  in  the  selected  menu  item.  The  new  data  will  be  sent  in  subsequent  uplinks  of  the 
item  until  another  value  is  entered  using  the  same  command. 


If  the  USER  DFBL  soft  function  set  has  been  selected,  pressing  F5  will  substitute  for  typing  "DP 
MC"  in  the  command. 


To  return  all  modified  altitude  values  in  the  menu  to  their  preadapted  default  values,  type  "DP 
MD"  or,  when  the  USER  DFBL  soft  function  key  set  has  been  selected,  press  F6. 


-  Ten^rarily  Modifying  Menu  Text  Altitude  Items 

To  make  a  one-time  change  to  an  altitude  in  a  menu  text  item  and  send  it  to  an  aircraft,  slew  to 
the  desired  menu  text  item  and  press  the  trackball  SELECT  key.  This  will  place  the  item  in  the 
common  console  Message  Composition  (MC)  view.  Type  the  substitute  replacement  altitude 
followed  by  a  space  and  the  FLED.  This  series  of  actions  will  send  the  modified  message  to  the 
selected  aircraft,  but  leave  the  original  message  in  the  menu  unchanged  for  future  uplinks. 

The  temporary  altitude  change  will  not  appear  in  the  menu  or  the  status  list.  However,  during  the 
transaction,  the  data  block  display  of  the  uplink  will  reflect  the  new  value  timesharing  with  the 
current  assigned  altitude. 

-  Inputs  to  Move  die  Menu 

The  menu  view  can  be  moved  to  any  position  on  the  display  by  typing  "M",  positioning  the  cursor 
in  the  header  area  of  the  menu  and  pressing  the  trackball  SELECT  key,  repositioning  the  menu 
with  the  trackball,  and  pressing  the  trackball  ENTER  key. 


-  Inputs  to  Suppress  or  Display  the  Menu 

The  menu  view  can  be  suppressed  by  typing  "SU",  positioning  the  trackball  cursor  in  the  header 
area  of  the  menu,  and  pressing  the  trackball  ENTER  key.  An  icon  located  over  the  upper  left 
comer  of  the  suppressed  menu  indicates  its  position.  Typing  "SU",  positioning  the  cursor  over 
the  icon  and  pressing  the  trackball  ENTER  key  will  unsuppress  (display)  the  menu. 

If  the  USER  DFBL  soft  function  set  has  been  selected,  pressing  F7  will  substitute  for  typing 
"SU". 
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COMMUNICATIONS  BACKUP 


-  Function 

The  communications  backup  service  permits  the  controller  to  compose  and  send  any  free  text 
message  using  Data  Link.  Unlike  the  other  Data  Link  services  in  which  only  one  transaction  for 
each  service  type  can  be  simultaneously  in  process  with  an  aircraft,  up  to  three  communications 
backup  messages  can  be  open  with  a  single  aircraft. 


-  Inputs  to  Send  a  Conununications  Backup  Message 

To  uplink  a  text  message  type  "DL  T "  a  message  up  to  20  characters  in  length  followed  by  a 
space,  and  a  FLID  (e.g.  "DL  T  CHECK  FOR  STUCK  MIC  AA123").  The  FLID  can  be  replaced 
by  "ALL"  to  uplink  the  message  to  all  eligible  aircraft  in  the  sector. 

If  the  USER  DFBL  soft  function  set  is  selected,  pressing  F3  will  substitute  for  "DL  T"  in  the 
conunand. 


-  Full  Data  Block  and  Status  List  Displays  on  Communications  Backup  Uplink 

No  FDB  display  is  provided  for  this  service.  During  the  transaction,  the  status  list  displays  the 
AID,  the  "FT"  message  type  abbreviation,  the  first  six  characters  of  the  text  message,  and  the 
current  status  abbreviation.  Upon  receipt  of  a  wilco,  "WDL"  is  displayed  for  six  seconds,  after 
which  the  entire  status  list  line  is  automatically  deleted. 


-  Unable  and  Time  Out  Displays  for  Communications  Backup 
and  Controller  Responses. 

If  the  flight  deck  responds  to  a  communications  backup  message  with  an  unable,  "UNB"  is 
displayed  in  yellow  in  the  status  field  of  the  status  list.  If  the  flight  deck  fails  to  downlink  a 
response  within  40  seconds,  "TIM"  is  displayed  in  yellow  in  the  status  field.  No  FDB  display  of 
these  failure  conditions  is  provided. 

In  either  case,  the  controller  can  close  the  transaction  and  delete  all  "UNB"  or  "TIM"  indicators 
by  typing  "D"  positioning  the  cursor  over  the  status  list  entry,  and  pressing  the  trackball  ENTER 
key.  Alternatively,  the  controller  may  type  "D  FT  "  and  the  FLID,  or  "D  ",  the  sequential  number 
of  the  line  in  the  status  list  (counting  from  the  top  of  the  list),  and  "  V/DLSL".  Thus,  "D  3 
V/DLSL”  would  delete  the  transaction  on  the  third  line  of  the  list. 
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APPENDIX  B 


AIRSPACE  TRAINING  PACKAGE 


LOCATION  IDENTIFIERS 
ALL  SECTORS 


AVE  = 
Br>R  = 
CZQ  = 
ECA  = 

ENI  = 
UN  = 
MODS 
MQOs 

OAKs 
OSI  s 
PYE  = 
RBLs 

SACs 
SAU  ^ 
SFOs 
SNSs 


ALCOA 

BOLDR 

DAANN 

STINS 


VORsA/ORTACs 


Avenal 
Big  Sur 
Clovis 
Manteca 

Mendocino 
Linden 
Modesto 
Morrow  Bay 

Oakland 
Woodside 
Point  Reyes 
Red  Bluff 

Sacramento 
Sausalito 
San  Francisco 
Salinas 


INTERSECTIONS 

BEBOP  BLATZ  BLUFF 

BRINY  CEDES  CLUKK 

LOZIT  PIRAT  SKUNK 

WAGES 
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I  SECT0R~i2 


VORaWORTACs 


AVE  = 

Avenal 

BSR  = 

Big  Sur 

CZQ  = 

Clovis 

MQOs 

Morrow  Bay 

OAKs 

Oakland 

OSI  = 

Woodside 

SFO  = 

San  Francisco 

SNS  = 

Salinas 

INTERSECTIONS 
BOLDR  SKUNK  WAGES 


SECTOR  24/17 


VORsA^ORTACs 


ECA  3s  Manteca 
ENI  =  Mendocino 
UN  =  Linden 
MOD=  Modesto 
OAK  =  Oakland 
SAC  =  Sacramento 
SFO  =  San  Francisco 

INTERSECTIONS 


CEDES 


SECTOR  35 


VQRa/VQRTACg 

MQOs  Morrow  Bay 
OAKs  OaMand 
OSI  =  Woodside 
SFO  s  San  Francisco 

INTERSECTIONS 

ALCOA  BEBOP  BLATZ  BLUFF 

BRINY  CLUKK  DAANN  PIRAT 


OAKLAND  ARTCC 
AND 

BAY  TRACON 


LETTER 

OF 

AGREEMENT 


EFFECTIVE:  December  1, 1993 

SUBJECT:  Terminal  Area  Control 

PURPOSE:  Establish  procedures  for  the  coordi¬ 
nation  and  control  of  air  traffic  between 
BAY  TRACON  and  Oakland  ARTCC. 

PROCEDURES: 

General: 

•  Aircraft  shall  be  routed  via  preferred  departure  and  arrival 
routes  as  specified  in  this  letter  of  agreement. 

•  Similar  performance  arrivals  or  departures  routed  via  the 
same  fix  shall  be  sequenced  in-trail. 
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•  The  minimum  separation  provided  by  the  CENTER  shall 
be  5  miles  constant  or  increasing. 

•  The  minimum  separation  provided  by  the  TRACON  shall 
be  7  miles  constant  or  increasing,  3  miles  constantly 
increasing  may  be  provided  to  the  CENTER  on 
departures.  The  first  center  controller  shall  ensure  the 
aircraft  are  provided  standard  CENTER  separation  before 
exiting  the  first  CENTER  sector. 

•  TRACON  releases  aircraft  for  turns  of  up  to  30  degrees. 

•  CENTER  releases  aircraft  for  turns  of  up  to  30  degrees. 

•  The  Transfer  Control  Point  (TCP)  shall  be  the  vertical 
extension  of  the  lateral  limits  of  TRACON  airspace. 
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ARRIVALS  TO;  SOUTH  FEEDER  from  SECTOR  12. 


ilEISl 

cleared  via: 


and  cross: 
at: 


BSR..SKUNK..BOLDR..SFO 


BOLDR  INTERSECTION 

KLCMOfeet 

and 

250  knots 


PBOK 

cleared  via: 

and  cross: 
at: 


BSR..OSI..SFO 


20milesSofOSI 
8,000  feet 


JE3S; 

cleared  via: 


BRINY..OSI..SFO 


and  cross: 
at; 


20milesWofOSI 

8,000  feet 

and 

250  knots 


PROPS; 

cleared  via: 

and  cross: 


BRINY..OSI..SFO 
20  miles  W  of  OSI 


ARRIVALS  TO:  NORTH  FEEDER  from  SECTOR  17/24 


cleared  via: 


to  cross: 


EBOeSi 

cleared  via: 

to  cross: 


CEDES..SFO 


CEDES 

11,000  feet  and 
250  knots 


CEDES..SFO 
CEDES 
10,000  feet 


iEESi 

cleared  via: 


to  cross: 


LOZIT..SFO 


LOZIT  INrERSECnON 

(22  MILES  NW  SFO) 

11,000  feet  and 
250  knots 


PROPS; 

cleared  via: 

to  cross: 


PYE..HADLY..OSI..SFO 

16  miles  SE  of  PYE 

(STINS  INTERSECTION) 

9,000  feet  or 
7,000  feet 
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DEPARTURES  FROM :  SUTRO-DR1  TO  SECTOR  12 


cleared  via: 

ASRLEO 


climbing  to: 

FL230 

(or  lower  if  requested) 

PROPS; 

cleared  via: 

ASHLED 

climbing  to: 

11,000  feet 

(or  lower  if  requested) 


JEIS 

cleared  via: 


ASRLED 


climbing  to: 

10,000  feet  (center  control  to  climb) 


PROPS; 

cleared  via: 

AS  RLED 

climbing  to: 

10,000  feet 

(or  lower  if  requested) 
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1  DEPARTURES  FROM; 

RICHMON  to 

SECTOR  17/24  ife 

jmi 

cleared  via; 

AS  FILED 


climbing  to; 

FL230 

(or  lower  if  requested) 


PROPS: 

cleared  via; 

AS  FILED 

climbing  to; 

11,000  feet 

(or  lower,  center  control  for  climb) 
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SECTOR  12 


STANDARD  OPERATING  PROCEDURE! 


Assignment  of  Airspace 

Sector  Boundaries 
Sector  Graphic  Chart 

Operation  of  Equipment 

Equipment  Preparation 
Radar  Settings 

Control  Procedures 

Speed  Restrictions 
Vectoring 
Sequencing 
Arrival  Procedures 
Departure  Procedures 
Point-out  Procedures 
Holding 

Flight  Plan  Information 

Sequencing  Flight  Progress  Strips 
Non-Radar  Oceanic  Coordination 
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ASSIGNMENT  OF  AIRSPACE 

Except  for  BAY  TRACON  Airspace,  Sector  12  has  jurisdiction 
within  the  boundaries  depicted,  at  FL230  and  BELOW. 
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EQUIP-MEMI  PREPARATiQN 

Video  maps  available  to  Sector  12: 

MAP  1  -  Navaids  and  intersections 
MAP  2  -  Airways  and  Sector  Boundaries 
MAP  3  -  High  Altitude  Sector  Boundaries 
MAP  4  -  Special  Areas 
MAP  5  -  E-MSAW 


RADAR  SETTINGS 

RANGE:  60  miles 


FILTER  KEYS  SELECTED:  WX1 ,  WX2.  MAPI ,  MAP2,  FDB, 

ALL  PRIMARIES,  SEL  BCN,  NON 
MODE  C,  ALT1  through  ALTS, 
(other  filter  keys  optional) 

ALTIMITER  SETTINGS:  SFO 


ALTITUDE  LIMITS:  000B242 
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MANDATORY  SPEED  RESTRICTIONS 

BAY  TRACON  ARRIVALS: 

Jets  shall  cross  BOLDR  intersection  (34  miles  SE  of  OAK) 
at  10,000  feet  and  250  knots. 


SEQUENCING 


Sequence  BAY  TRACON  arrivals  from  the  south  cleared  to 
BAY  TRACON  via  BSR..SKUNK..BOLDR..SFO.  Aircraft 
operating  above  FL240  shall  be  cleared  to  FL240  by  the 
previous  sector. 

*  BSR  =  BIG  SUR  VORTAC 
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BAY  TRACON  AIRPORTS: 

JET  ARRIVALS 


cleared  via: 


BSR..SKUNK..BOLDR..SFO 


and  cross: 


BOLDR  INTERSECTION 


at: 


and 


10,000  feet 


250  knots 


*BOLX>R=OAK151034 
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cleared  via: 


BSR..OSI..SFO 
and  cross: 

20  MILES  S  of  OSI 


at: 


8,000  feet 


NOTE:  High  performance  turboprops 
(E120,SW3,  etc.)  may  be  cleared  via 
the  jet  procedures  at  controller's 
discretion. 


•  OSI  =  WOODSIDE  VOTAC 


BAY  TRACON  AIRPORTS: 


JETS  are  cleared  as  filed,  climbing  to  FL230,  or  lower 
altitude  if  requested.  Oakland  ARTCC  has  control  for  turns. 

PROPS  are  cleared  as  filed,  climbing  to1 1 ,000  feet,  or  lower 
altitude  if  requested,  and  are  sector  12's  control  for  climb. 
Oakland  ARTCC  has  control  for  turns. 

When  traffic  permits,  a  temporary  altitude  of  FL230 
should  be  entered  into  the  data-block  of  all  aircraft 
requesting  FL240  or  above,  and  a  hand-off  should  be 
made  to  the  overlying  sector,  (see  Altitude  Coord.) 

When  traffic  does  not  permit  a  climb  to  FL230,  climb 
the  aircraft  to  the  highest  available  altitude  in  your 
airspace,  and  execute  a  hand-off  to  the  adjoining 
sector. 


POINT  OUT  PROCEDURES 

Whether  or  not  the  handoff  has  been  accepted,  the 
transferring  controller  shall  make  all  necessary  point  outs 
within  the  same  altitude  stratum  (low  to  low  or  high  to  high) 
unless  otherwise  coordinated. 


HOLDING 


SKUNK  (published) 

Hold  SE  of  SKUNK  on  the  OAK151  radial. 

Left  turns 

Standard  leg 

Min.  altitude  5,000  feet 

Max.  altitude  FL450 


FLIGHT  PLAN  INFORMATION 

SEQUENCING  FLIGHT  PROGRESS  STRIPS 
3  Suggested  Bayheaders: 


ACTIVE: 

PROPOSAL: 

SECTOR  12: 


Used  for  active  flight  plans. 

Proposal  bay  for  all  departures  or 
pop'Ups. 

Bay  for  pending  strips. 
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NONRADAR/OCEANIC  COORDINATION 

The  next  sector/facility  will  have  all  necessary  information  on 
nonradar/oceanic  flights.  Acceptance  of  track  control  shall 
constitute  approval  to  enter  the  next  sector's  or  facility's 
airspace. 


ALTITUDE  COORDINATION 

Acceptance  of  a  hand-off  by  the  next  center  sector,  of  an 
aircraft  with  a  temporary  altitude  in  the  data  block,  shall 
constitute  approval  of  that  altitude. 


AVE  =  Avenal  VORTAC 

BSR  =  Big  Sur  VORTAC 

CZQ=  Fresno  VORTAC 

OAK  =  Oakland  VORTAC/Airport 

OSI  =  Woodside  VORTAC 

SFO=  San  Fransisco  VORTAC/Airport 

SNS  =  Salinas  VORTAC 
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Assignment  of  Airspace 

Sector  Boundaries 
Sector  Graphic  Chart 

Operation  of  Equipment 

Equipment  Preparation 
Radar  Settings 

ppntroi  ProoedMres 

speed  Restrictions 
Vectoring 
Sequencing 
Arrival  Procedures 
Departure  Procedures 
Point-out  Procedures 
Holding 

Fiiqht  Pian  information 

Sequencing  Flight  Progress  Strips 
Non-Radar  Oceanic  Coordination 
Altitude  Coordination 
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Except  for  BAY  TRACON  airspace,  Sector  24/17  has  jurisdiction 
within  the  boundaries  depicted,  at  FL230  and  BELOW. 
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Video  maps  available  to  Sector  17/24: 

MAP  1  -  Navaids  and  intersections 

MAP  2  -  Sector  Boundaries 

MAP  3  -  High  Altitude  Sector  Boundaries 

MAP  4  -  Special  Areas 

MAP  5  -  E-MSAW 


t 


FILTER  KEYS  SELECTED:  WX1 ,  WX2,  MAPI ,  MAP2,  FDB, 

ALL  PRIMARIES,  SEL  BCN,  NON 
MODE  C,  ALT  1  through  ALTS, 
(other  filter  keys  optional) 

ALTIMITER  SETTINGS:  SFO,  OAK 

ALTITUDE  LIMITS:  000B242 
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BAY  TRACON  ARRIVALS: 


Jets  shall  cross  CEDES  intersection  (32  miles  SW  of  MOD) 
at  1 1 ,000  feet  and  250  knots. 

(MOD  =  Modesto  VOR/DME) 


SEQUENCING 


Sequence  BAY  TRACON  arrivals  from  the  east  cleared  into 
BAY  TRACON  via  CEDES.. SFO.  Aircraft  operating  above 
16,000  feet  shall  be  descended  to  16,000  feet  by  the 
previous  sector,  unless  othen/vise  coordinated.  Acceptance 
of  a  handoff  with  other  than  16,000  feet  displayed  in  the 
temporary  altitude  shall  be  considered  coordination. 
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ARRIVAIL  PROQgpgRg$ 

BAY  TRACON  AIRPORTS: 

JET  ARRIVALS 

Cleared  via: 

CEDES..SFO 

and  cross: 

CEDES  INTERSECTION 

at: 

11,000  feet 
and 

250  knots 

•CEDES  =  MOD245032 
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cleared  via; 


CEDES..SFO 


and  cross: 


at; 


CEDES 

10,000  feet 


NOTE:  High  performance  turboprops 
(E120,SW3,  etc.)  may  be  cleared  via 
the  jet  procedures  at  controller's 
discretion. 


DEPARTURE  PROCEDURES 


BAY  TRACON  AIRPORTS: 


JETS  are  cleared  as  filed,  climbing  to  FL230,  or  lower 
altitude  if  requested.  Oakland  ARTCC  has  control  for  turns. 

PROPS  are  cleared  as  filed,  climbing  to  11 ,000  feet,  or 
lower  altitude  If  requested.  Oakland  ARTCC  has  control  for 
turns  and  climb. 

When  traffic  permits,  a  temporary  altitude  of  FL230 
should  be  entered  into  the  data-block  of  all  aircraft 
requesting  FL240  or  above,  and  a  hand-off  should  be 
made  to  the  overlying  sector,  (see  Altitude  Coord.) 

When  traffic  does  not  permit  a  climb  to  FL230,  climb 
the  aircraft  to  the  highest  available  altitude  in  your 
airspace,  and  execute  a  hand-off  to  the  adjoining 
sector. 


POINT  OUT  PROCEDURES 


Whether  or  not  the  handoff  has  been  accepted,  the 
transferring  controller  shall  make  all  necessary  point  outs 
within  the  same  altitude  stratum  (low  to  low  or  high  to  high) 
unless  otherwise  coordinated. 
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HOLDING 


CEDES  (published) 

Hold  SE  of  CEDES  on  the  MOD  245  radial. 

Left  turns 

Standard  leg 

Min.  altitude  5,000  feet 

Max.  altitude  FL450 


* 


FUGHT  PLAN  INFORMATION 

SEQUENCING  FLIGHT  PROGRESS  STRIPS 
4  Suggested  Bayheaders: 


ARRIVALS: 

DEPARTURES: 

PROPOSAL: 

SECTOR  17/24: 


Used  for  arrival  flight  plans. 

Used  fo  departure  flight  plans. 

Proposal  bay  for  all  departures  or 
pop-ups. 

Used  for  all  other  flight  plans. 


I 
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NONRADAR/OCEANIC  COORDINATION 

The  next  sector/facility  will  have  all  necessary  information  on 
nonradar/oceanic  flights.  Acceptance  of  track  control  shall 
constitute  approval  to  enter  the  next  sector's  or  facility's 
airspace. 

ALTITUDE  COORDINATION 

Acceptance  of  a  hand-off  by  the  next  center  sector,  of  an 
aircraft  with  a  temporary  altitude  in  the  data  block,  shall 
constitute  approval  of  that  altitude. 


VQRTACg  VOR/DMEs 

OAK  =  Oakland  MOD  =  Modesto 

SAC  =  Sacramento  SFO  =  San  Francisco 

ECA  =  Manteca 
LIN  =  Linden 
ENI  =  Mendocino 
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OAKLAND  CENTER 

Sector  35 

STANDARD  OPERATING  PROCEDURE! 


Airgpacg 
Sector  Boundaries 
Sector  Graphic  Chart 


jration  of  Equipment 

Equipment  Preparation 
Radar  Settings 


Controi  Procedures 

Speed  Restrictions 
Vectoring 
Sequencing 
Arrival  Procedures 
Departure  Procedures 
Point-out  Procedures 
Holding 


Elight  Plan  IntormetiQn 

Sequencing  Flight  Progress  Strips 
Non-Radar  Oceanic  Coordination 
Altitude  Coordination 
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RSPACE 


Except  for  BAY  TRACON  airspace,  Sector  35  has  jurisdiction  within 
the  boundaries  depicted,  at  FL230  and  BELOW,  and  SURFACE  and  UP. 


45 

^f!  230 

111.10 


41 

^  fl230 

133.85 


BAY  TRACON 
^140 
122,05 


45 

oceanic 

111.10* 


SECTOR  35 

SFC-FL230/SFCANDUP 


118,75 


=CniJ  A  R  a  i  ;i;i  =(vj;fai 


Video  maps  available  to  Sector  35: 

MAP  1  -  Navaids  and  Intersections 
MAP  2  -  Airways  and  Sector  Boundaries 
MAP  3  -  High  Altitude  Sector  Boundaries 
MAP  4  -  Special  Areas 


250  miles 


FILTER  KEYS  SELECTED:  WX1 .  WX2,  STROBE,  MAPI , 

MAP2,  FDB,  ALL  PRIMARIES. 
SELBCN,  NON  MODEC.ALTI 
through  ALTS. 

(Other  keys  optional) 

ALTIMETER  SETTINGS:  SFO 
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BAY  TRACON  ARRIVALS: 


Jets  shall  cross  20  miles  southwest  of  OSI  VORTAC  (BRINY 
INTERSECTION)  at  8,000  feet  and  250  knots. 


*  OSf  =  WOODSlOe  VORTAC 


SEQUENCING 


Sequence  oceanic  arrivals  cleared  to  BAY  TRACON  via 
BRINY..OSI..SFO 
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ABBIYALPRQCEPURES 


BAY  TRACON  AIRPORTS: 


JET  ARRIVALS 

cleared  via: 

ALCOA..BRINY..OSI..SFO 

or 

CLUKK..BRINY..OSI..SFO 

or 

BEBOP..BRINY..OSI..SFO 


and  cross: 

BRINY  INTERSECTION 

at: 

8,000  FEET 

and 

250  KNOTS 

*  ENI  =  MENDOCINO  VORTAC 

PYE  =  POINT  REYES  VORTAC 
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BAY  TRACON  AIRPORTS: 


JETS  are  cleared  as  filed,  climbing  to  10,000  feet.  Oakland  ARTCC 
has  control  for  turns  and  speed. 

PROPS  are  cleared  to  10,000  feet,  or  requested  lower 
altitude,  and  are  not  sector  35's  control  for  climb. 

When  traffic  does  not  permit  a  climb  to  requested 
altitude,  climb  the  aircraft  to  the  highest  available 
altitude  in  your  airspace,  and  execute  a  hand-off  to  the 
adjoining  sector,  (see  Altitude  Coord.) 

POINT  OUT  PROCEDURES 

Whether  or  not  the  handoff  has  been  accepted,  the  transferring 
controller  shall  make  all  necessary  point  outs  within  the  same 
altitude  stratum  (low  to  low  or  high  to  high)  unless  otherwise 
coordinated. 

HOLDING 

RAINS  (published) 

Hold  SW  of  RAINS  (OAK219059)  on  the  OAK  219  radial. 

Right  turns 
Standard  leg 
Min.  altitude  14,000  feet 
Max.  altitude  FL450 


*  OAK  =  OAKLAND  VORTAC 
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NONRADAR/OCEANIC  COORDINATION 


The  next  sector/facility  will  have  all  necessary  information  on 
nonradar/oceanic  flights.  Acceptance  of  track  control  shall 
constitute  approval  to  enter  the  next  sector's  or  facility's  airspace. 


ALTITUDE  COORDINATION 

Acceptance  of  a  hand-off  by  the  next  center  sector,  of  an 
aircraft  with  a  temporary  altitude  in  the  data  block,  shall 
constitute  approval  of  that  altitude. 


ENI  =  Mendocino  VORTAC 
PYE  =  Point  Reyes  VORTAC 
OAK  =  Oakland  VORTAC 
MOO  =  Morrow  Bay  VORTAC 
OSI  =  Woodside  VORTAC 
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OAKLAND  CENTER 


SECTOR  40/41 


STANDARD  OPERATING  PROCEDURES 


Assignment  of  Airspace 

Sector  Boundaries 
Sector  Graphic  Chart 


Operation  of  Equipment 

Equipment  Preparation 
Radar  Settings 

Oontroi  Procedures 

Speed  Restrictions 
Vectoring 
Sequencing 
Arrival  Procedures 
Departure  Procedures 
Point-out  Procedures 
Holding 


Flight  Plan  Information 

Sequencing  Flight  Progress  Strips 
Non-Radar  Oceanic  Coordination 
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Except  for  BAY  TRACON  airspac,  Sector  41  has  jurisdiction 
within  the  boundaries  depicted,  at  FL230  and  BELOW. 


OAKLAND  ARTCC 
SECTOR  41 
SURFACE  TO  FL  230 


Video  maps 
MAPI 
MAP  2 
MAP  3 
MAP  4 
MAPS 


available  to  Sector  40/41 : 

-  Navaids  and  Intersections 

-  Airways  and  Sector  Boundaries 

-  High  Altitude  Sector  Boundaries 

-  Special  Areas 

-  E-MSAW 


RADAR  SETTINGS 


RANGE:  60  miles  (centered  5  NW  of  STS 

VOR) 


FILTER  KEYS  SELECTED:  WX1 ,  WX2.  STROBE,  MAPI , 

MAP2,  FDB,  ALL  PRIMARIES, 
SEL  BCN,  NON  MODE  C,  ALT1 
through  ALTS. 

(other  filter  keys  optional) 

ALTIMITER  SETTINGS:  SFO,  OAK 

ALTITUDE  LIMITS:  000B242 
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MANDATORY  SPEED  RESTRICTIONS 
BAY  TRACON  ARRIVALS: 

Jets  shall  cross  LOZIT  INTERSECTION  (22  miles  NW  of 
SFO)  at  1 1 ,000  feet  and  250  knots. 


SEQUENCING 


Sequence  BAY  TRACON  arrivals  from  the  north  cleared  to 
BAY  TRACON  via  PYE..L02IT..SF0.  Aircraft  operating 
above  FL240  shall  be  assigned  FL240  by  the  previous 
sector. 


ENI  =  MENDOCINO  VORTAC 
PYE  =  POINT  REYES  VORTAC 
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ARRIVAL  PROCEDURES 

BAY  TRACON  AIRPORTS: 

JET  ARRIVALS 

Cleared  via: 

PYE..LOZIT..SFO 

and  cross: 

LOZIT  INTERSECTION 

(22  MILES  NW  of  SFO) 

at: 

11,000  feet 

and 

250  knots 
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cleared  via: 


PYE..LOZIT..SFO 


and  cross: 

LOZIT  INTERSECTION 


at: 


9,000  feet 
or 

7,000  feet 


NOTE:  High  performance  turboprops 
(E120,SW3,  etc.)  may  be  cleared  via 
the  jet  p'-ocedures  at  controller's 
discretion. 

*  PYE  =  POINT  REYES 


DEPARTURE  PROCEDURES 

BAY  TRACON  AIRPORTS: 


JETS  are  cleared  as  filed,  climbing  to  FL230,  or  lower 
altitude  if  requested.  Oakland  ARTCC  has  control  for  turns 
and  speed. 


PROPS  are  cleared  to  10,000  feet,  or  lower  altitude  if 
requested,  and  are  Oakland  ARTCC's  control  for  climb. 


When  traffic  permits,  a  temporary  altitude  of  FL230 
should  be  entered  into  the  data-block  of  all  aircraft 
requesting  FL240  or  above,  and  a  hand-off  should  be 
made  to  the  overlying  sector,  (see  Altitude  Coord.) 

When  traffic  does  not  permit  a  climb  to  FL230,  climb 
the  aircraft  to  the  highest  available  altitude  in  your 
airspace,  and  execute  a  hand-off  to  the  adjoining 
sector. 

POINT  OUT  PROCEDURES 


Whether  or  not  the  handoff  has  been  accepted,  the 
transferring  controller  shall  make  all  necessary  point  outs 
within  the  same  altitude  stratum  (low  to  low  or  high  to  high) 
unless  othenvise  coordinated. 
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HOLPtNG 


PYE  (published) 

Hold  NW  of  PYE  on  the  PYE  325  radial. 

Right  turns 

Standard  leg 

Min.  altitude  5,000  feet 

Max.  altitude  FL450. 


*  PYE  =  POINT  REYES  VORTAC 

FUGHT  PLAN  INFORMATION 

SEQUENCING  FLIGHT  PROGRESS  STRIPS 
3  Suggested  Bayheaders: 


ACTIVE: 

PROPOSAL: 

SECTOR  41: 


Used  for  active  flight  plans. 

Proposal  bay  for  all  departures  or 
pop-ups. 

Bay  for  pending  strips. 
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NONRADAR/OCEANIC  COORDINATION 


The  next  sector/facility  will  have  all  necessary  Information 
on  nonradar/oceanic  flights.  Acceptance  of  track  control 
shall  constitute  approval  to  enter  the  next  sector's  or 
facility's  airspace. 


ALTITUDE  COORDINATION 

Acceptance  of  a  hand-off  by  the  next  center  sector,  of  an 
aircraft  with  a  temporary  altitude  in  the  data  block,  shall 
constitute  approval  of  that  altitude. 


ENI  =  Mendocino 
PYE  =  Point  Reyes 
SGD  =  Scaggs  Island 
SAU  =  Sausalito 
OAK  =  Oakland 
SAC  =  Sacramento 
RBL  =  Red  Bluff 
SFO  =  San  Francisco 


B-43 


ISSS  PROTOTYPE  EVALUATION 


NAME: 


Briefly  describe  your  exposure  to,  or  experience  with,  the  ISSS  common  console  prior  to  this 
study: 


QUESTIONNAIRE  INSTRUCTIONS: 

The  ISSS  common  console  prototype  that  is  being  used  in  this  study  was  assembled  to  provide  a 
simulation  environment  in  which  Data  Link  ATC  services  could  be  developed  and  tested.  It  is  not 
intended  to  be  an  exact  copy  of  the  real  common  console  or  to  emulate  all  of  the  functionality  of 
the  actual  ISSS  system.  However,  in  order  to  serve  as  a  valid  test  bed  for  evaluations,  it  must 
faithfully  reproduce  those  aspects  of  the  common  console  and  of  the  ISSS  controller’s  task  that 
could  affect  a  controller's  Data  Link  performance  or  the  judgments  he  or  she  would  be  asked  to 
make  about  Data  Link  during  a  simulation. 

This  questionnaire  is  aimed  at  getting  your  inputs  regarding  those  characteristics  of  the  prototype 
system  that  may  need  to  be  modified  or  improved  in  order  to  optimally  support  Data  Link 
development  and  testing. 

Please  answer  the  following  questions  based  on  your  best  professional  Judgement,  regardless  of 
the  level  of  experience  that  you  have  had  with  actual  ISSS  software  and  equipment. 

Remember,  you  are  evaluating  the  ability  of  the  prototype  to  support  Data  Link  testing  in  the 

ISSS  environment,  ns£  necessarily  its  ability  to  perfectly  simulate  all  ISSS 

ctq)abilities. 

1.  Do  you  feel  that  the  prototype  hardware  (e.g.  console  design,  keyboard,  trackball,  display 
surface,  audio  communications  system)  is  sufficiently  realistic  to  support  Data  Link  development 
and  testing? 

YES  _ 


NO 
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If  no,  please  explain: 


2.  Are  the  appearances  of  the  screen  graphics  and  text  sufficiently  realistic  to  support  Data  Link 
development  and  testing? 

YES  _ 

NO _ 

If  no,  please  explain: 


3.  Are  the  dynamic  aspects  of  die  simulation  sufficiently  realistic  in  terms  of  system  respcmse  time 
and  aircraft  movement? 

YES _ 

NO _ 

If  no,  please  explain: 


4.  Does  the  prototype  currently  support  a  sufficient  number  of  views,  functions  and  command 
inputs  of  the  ISSS  common  console  to  permit  realistic  testing  of  Data  Link? 

YES  _ 

NO _ 

If  no,  please  explain: 
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5.  What  other  specific  changes  to  the  prototype  hardware  or  software  are  needed  to  adequately 
support  Data  Link  evaluation? 


REVIEWER  S  NAME 


CONTROLLER  EVALUATION 
INITIAL  DATA  LINK  EN  ROUTE  SERVICES 

ISSS  COMMON  CONSOLE 


DESIGN  REVIEW  BOOKLET 


INSTRUCTIONS 

This  booklet  contains  a  series  of  simulation  exercises  and  questions  which  will  permit  you  to 
independently  review  and  evaluate  the  designs  of  the  candidate  ISSS  services.  The  goal  of  this 
review  is  to  identify  those  aspects  of  the  designs  which  are  acceptable  as  presented  and  those 
which  will  requite  modification. 

The  booklet  contains  six  sections  which  address  individual  design  features  or  services.  Each 
section  corresponds  to  one  of  the  sections  in  the  DESIGN  DESCRIPTION  BOOKLET. 

You  should  begin  your  review  of  each  section  by  carefully  reading  the  DESIGN  DESCRIPTION. 
Next,  working  with  your  partner,  complete  the  SCRIPTED  EXERCISE  FRAME  in  this  booklet 
that  is  associated  with  the  description.  Finally,  working  on  your  own,  answer  all  questions  for  the 
section  and  record  any  recommendations  for  design  changes.  Explain  your  reasons  for  suggesting 
these  changes. 

Be  sure  to  read  the  DESIGN  DESCRIPTION  for  a  section  before  entering  the  command  to  start 
the  next  scripted  exercise  frame  on  the  prototype  common  console. 


Remember,  your  main  task  is  to  concentrate  on  completing  the  evaluation  booklet.  We  are  doing 
the  review  in  the  ISSS  prototype  laboratory  so  that  you  can  examine  the  service  designs  as  you 
work  on  the  booklet.  The  exercises  are  designed  to  permit  each  pair  of  controllers  to  work  at 
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their  own  pace.  During  this  session,  it  is  not  importart  to  maintain  precise  control  of  the  simulated 
air  traffic. 


NOTE:  AH  exercise  scenarios  occur  in  Sector  41  of  the  Oakland  airspace.  We  suggest  that  you 
set  the  range  on  the  ISSS  common  console  to  150  miles  for  best  viewing  of  the  displays. 


EXERCISE  FRAME  1 

STATUS  LIST,  DATA  BLOCK  DISPLAY  AND  ENTRY  ERROR  MESSAGES 
Read  the  entire  Full  Data  Block,  Status  List  and  Entry  Error  description. 

Then,  select  Frame  1  from  the  menu  to  start  this  exercise. 


Frame  Overview: 

This  frame  is  a  static  representation  of  the  situation  display.  It  presents  a  sample  status  li.st  and 
several  data  blocks  to  illustrate  status  list  format  and  indicator  abbreviations.  Data  Link 
symbology,  and  basic  move  and  suppress  commands. 

Complete  the  Following  Exercises: 

1.  Observe  Full  Data  Block  Equipage  and  Eligibility  Symbols 

AA5621  -  No  symbol:  not  equipped  for  Data  Link  communication 

UAL666  -  Open  diamond:  equipped  for  Data  Link  communication, 
but  this  sector  not  eligible 


Other  aircraft  in  sector  -  Filled  diamond:  equipped  for  Data 
Link  communication  and  this 
sector  is  eligible 


2.  Observe  Service  Abbreviations,  Message  Content  and  Status 
Indicators  in  Status  List  (and  FDB) 
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USA200  -  You  have  uplinked  an  assigned  altitude  of  1 1,000 
ft.  and  message  is  in  the  sent  state  as  shown  by 
the  status  list  abbreviation  SNT  and  the 
timesharing  display  in  the  second  line  of  the  FDB. 

SWA283  -  You  have  uplinked  an  interim  altitude  of  7000  ft. 
and  the  pilot  has  responded  UNABLE  as  shown  by  the 
status  list  and  FDB  abbreviation  UNB  in  yellow. 

USA  561  -  You  have  uplinked  menu  text  item  A  and  the  pilot 
has  responded  STANDBY  as  shown  by  the  status  list 
and  FDB  abbreviation  STB  in  yellow. 

DAL  1321  -  You  have  handed  this  aircraft  off  to  another 
sector  with  transfer  of  communication  in  the 
manual  mode.  The  system  has  prepared  a  TOC 
message  for  uplink  as  shown  by  the  HLD  (held) 
abbreviation  in  the  status  list. 

UAL  162  -  You  have  sent  a  backup  comunications  message  "CALL 
COMPANY"  and  the  pilot  has  responded  Wilco. 

AA776  -  You  uplinked  an  assigned  altitude  of  1 1,000  ft.  and 
the  pilot  has  failed  to  respond  within  40  seconds  as 
shown  by  the  status  list  and  FDB  displays  of  TIM 
(Time  Out). 


3.  Move  the  status  list  to  another  position  on  the  situation 
display. 


4.  Suppress  the  status  list  and  retrieve  it  back  to  the  situation 
display. 


When  you  have  completed  this  exercise,  type  "EXIT"  to  end  the  exercise  frame.  Individually 
answer  all  questions  in  this  section  of  the  review  booklet,  then  turn  to  the  next  service  description. 
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STATUS  LIST.  DATA  BLOCK  AND  INPUT  ERROR  MESSAGE  REVIEW  QUESTIONS: 


1.  Does  the  description  accurately  represent  the  design  and 
operation  of  the  Status  List  that  you  examined  on  the  ISSS 
prototype? 


_  YES,  THE  DESCRIPTION  IS  CORRECT 

_ NO.  rr  DOESNT  MATCH 

Describe  those  aspects  of  the  description  that  did  not  match  your  observations  - 


2.  Do  you  feel  that  the  Status  List  in  addition  to  the  FDB  will 
be  necessary  for  operational  implementation?  Why  or  why  not? 


3.  Do  the  abbreviated  status  messages  (SNT,  HLD,  WIL  etc.)  and 
yellow  alert  codes  used  in  the  Status  List  provide  sufficient 
information?  Are  they  easy  to  interpret? 


4.  Are  the  abbreviations  for  the  services  (TC,  AA,  lA,  MT,  FT) 
used  in  the  Status  List  adequate? 


5.  Are  the  data  block  filled  and  open  diamond  symbols  used  to 
indicate  Data  Link  equipage  and  eligibility  easy  to  interpret? 
Do  you  foresee  any  problems  in  discriminating  them  from  one 
another  or  from  other  symbology  on  the  display? 


C-6 


6.  Are  the  inputs  used  to  move  and  suppress/recover  the  Status 
List  appropriate  and  easy  to  perform? 


7.  Do  you  feel  that  the  Data  Link  entry  error  messages  presented 
in  the  description  will  provide  adequate  feedback  about  the 
source  of  input  errors? 


8.  What  should  be  done  to  improve  the  design  of  the  Status  List, 

FDB  displays  and  entry  error  messages  as  implemented  in  the 
prototype?  Include  any  changes  suggested  by  your  answers  to 
questions  2.-  7.  above. 

_ THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 

CHANGES  ARE  DESIRABLE  OR  NEEDED 


_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 
CHANGES  ARE  NEEDED,  fim  THE  FOLLOWING  WOULD  BE 
DESIRABLE:  (describe) 


_  THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  - 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 


¥ 
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EXERaSEFRAME2 
TRANSFER  OF  COMMUNICATION 


Read  the  entire  transfer  of  communication  service  description.  Then,  select  Frame  2  from  the 
menu  to  start  this  exercise. 


Frame  Overview: 

This  frame  is  designed  to  permit  you  to  focus  on  sending  the  TOC  service  to  aircraft  departing  the 
sector.  Aircraft  in  this  scenario  will  approach  the  boundary  and  exit  your  sector. 


Complete  the  Following  Exercises: 

1.  Send  Automatic  TOC 

-  Set  TOC  mode  to  automatic 

-  Handoff  several  aircraft  and  observe  FDB  and  Status  list  displays  change  as  handoff  is 
accepted,  TOC  is  uplinked,  and  pilot  wilcoes  message. 


2.  Observe  TOC  Failures 

-  Keep  TOC  mode  in  automatic 

-  Tell  simulation  pilot  to  return  an  UNABLE  response  to  the  TOC  message  you  will  be  sending  to 
an  identified  aircraft. 

-  Handoff  the  aircraft,  observe  unable  displays  in  FDB  and  Status  list,  and  maintenance  of 
eligibility  at  your  sector. 

-  Qose  transaction  by  deleting  displays. 


-  Repeat  above  sequence  with  another  aircraft  requesting  the  simulation  pilot  to  allow  message  to 
TIMEOUT. 


3.  Send  Manual  TOC 


-  Set  TOC  mode  to  Manual. 

-  Handoff  several  aircraft.  Note  HELD  messages  in  Status  List  when  handoffs  are  accepted. 
Observe  FDB  and  Status  List  displays  when  you  uplink  held  messages,  and  when  pilot  wilcoes 
message. 


4.  Send  an  Automatic  TOC  from  Manual  Mode 

-  Keep  TOC  mode  in  Manual. 

-  Handoff  several  aircraft,  adding  the  "S"  to  some  handoff  commands  to  automatically  send  the 
TOC  message. 


5.  Force  and  Steal  Eligibility 

-  Force  Data  Link  eligibility  for  several  aircraft  to  another  sector  without  a  handoff.  Send  the  new 
frequency  to  the  aircraft  by  voice. 

-  Force  Data  Link  eligibility  for  a  second  group  of  aircraft  to  another  sector  without  a  handoff. 
Send  the  new  frequency  by  Data  Link  by  adding  the  "S"  to  the  force  command. 

-  Steal  track  control  and  Data  Link  eligibility  for  several  aircraft  that  you  have  already  handed  off 
and  transferred  to  a  new  sector.  Include  the  "S"  in  the  steal  conunand  to  send  your  frequency  to 
the  aircraft. 

-  Steal  Data  Link  eligibility  for  several  aircraft  that  you  have  already  handed  off  and  transferred  to 
a  new  sector  and  simultaneously  force  it  to  another  sector.  Include  the  "S"  in  the  command  to 
send  the  new  frequency  to  the  aircraft. 


When  you  have  completed  this  exercise,  type  "EXIT"  to  end  the  exercise  frame.  Individually 
answer  all  questions  in  this  section  of  the  review  booklet,  then  turn  to  the  next  service  description. 
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TRANSFER  OF  COMMUNICATION  REVIEW  QUESTIONS: 


1.  Does  the  (Ascription  accurately  represent  the  design  and 
operation  of  the  TOC  service  that  you  examined  on  the  ISSS 
prototype? 


_  YES,  THE  DESCRIPTION  IS  CORRECT 

_ NO,  IT  DOESN’T  MATCH 

Describe  those  aspects  of  the  description  that  did  not  match  your  observations  -- 


2.  Is  the  up-arrow  in  the  data  bl(x:k  an  effective  way  to  indicate 
that  a  TOC  message  has  been  sent  and  that  Data  Link 
eligibility  is  changing? 


3.  Is  a  display  of  the  currently  active  TOC  mode  (AUTO/MANUAL) 
needed? 


4.  Is  the  reversion  of  the  Data  block  eligibility/equipage  symbol 
from  an  up-arrow  to  a  yellow  filled  diamond  adequate  for 
notifying  the  controller  that  the  pilot  has  failed  to  respond 
quickly  enough  (Time  Out)  or  that  an  Unable  response  has  been 
received? 


5.  Are  the  inputs  for  "stealing"  and  "forcing"  Data  Link 
eligibility  logical  and  appropriate? 
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6.  What  should  be  done  to  improve  the  design  of  the  TOC  service 
as  implemented  in  the  ISSS  prototype?  Include  any  changes 
suggested  by  your  answers  to  questions  2-5. 


_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 
CHANGES  ARE  DESIRABLE  OR  NEEDED 


_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 
CHANGES  ARE  NEEDED,  fiUI  THE  FOLLOWING  WOULD  BE 
DESIRABLE;  (describe) 


% 


_  THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  - 
THE  FOLLOWING  CHANGES  MUST  BE  MADE; 


4 
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EXERCISE  FRAME  3 

ALTITUDE  ASSIGNMENT  -  MANUAL  ENTRY 

Read  the  entire  altitude  assignment  description. 

Then,  select  Frame  3  from  the  menu  to  start  this  exercise. 


Framg  QygYisw: 

This  frame  is  designed  to  permit  you  to  focus  on  sending  Altitude  Assignments  using  the  manual 
entry  procedure.  Aircraft  in  this  scenario  will  be  moving  through  your  sector,  and  you  will  not  be 
required  to  accept  or  offer  handoffs. 


Complete  the  Following  Exercises: 

1.  Send  Altitude  Messages 

-  Send  Altitude  Assignments  to  several  adrcraft  using  both  keyboard  and  trackball  methods  of 
entering  FUDs. 

-  Observe  FDB  and  Status  List  indicators  of  message  content  and  changes  in  status  as  message  is 
sent  and  wilcoed. 

-  Repeat  the  above  steps  for  several  new  aircraft  sending  Interim  Altitudes. 


2.  Observe  "Failed"  Messages 

-  Identify  several  aircraft  to  the  simulation  pilot  and  tell  him  to  respond  UNABLE. 

-  Observe  Unable  displays  in  FDB  and  Status  List. 

-  Close  transaction  and  clear  displays  with  delete  command. 

-  Repeat  above  steps  requesting  a  TIME  OUT  from  simulation  pilot. 


When  you  have  completed  this  exercise,  type  "EXIT”  to  end  the  exercise  frame.  Individually 
answer  all  questions  in  this  section  of  the  review  booklet,  then  turn  to  the  next  service  description. 
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ALTITUDE  ASSIGNMENT  -  MANUAL  ENTRY  REVIEW  QUESTIONS: 

1.  Does  the  description  accurately  represent  the  design  and 
operation  of  the  Altitude  Assignment  service  that  you  examined 
on  the  ISSS  prototype? 

_  YES,  THE  DESCRIPTION  IS  CORRECT 

_  NO,  IT  DOESNT  MATCH 

Describe  those  aspects  of  the  description  that  did  not  match  your  observations  - 


2.  Are  the  inputs  used  to  send  altitude  assignments  and 
interim  altitudes  appropriate? 


3.  Does  the  timesharing  data  block  altitude  display  followed  by 
"S"  provide  useful  and  adequate  feedback  for  indicating  the 
Sent  status  and  content  of  an  altitude  message? 


4.  Are  the  Unable  and  Time  Out  displays  in  the  data  block 
adequate  for  alerting  the  controller?  Are  the  procedures  used 
to  delete  these  displays  and  close  the  transaction 
appropriate? 


S.  Do  you  foresee  any  significant  possibility  that  controllers 
will  make  undetected  errors  when  uplinking  altitudes  using 
this  service?  If  yes,  please  explain. 


6.  What  should  be  done  to  improve  the  design  of  the  Altitude 
Assignment  service  as  implemented  on  the  ISSS  prototype? 
Include  any  changes  suggested  by  your  answers  to  questions 
2.-5. 
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_ THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 

CHANGES  ARE  DESIRABLE  OR  NEEDED 


_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 
CHANGES  ARE  NEEDED,  BiH  THE  FOLLOWING  WOULD  BE 
DESIRABLE:  (describe) 


_  THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  ~ 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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EXERCISE  FRAME  4 


INITIAL  CONTACT 

Read  the  entixe  Initial  Contact  service  description. 

Then,  select  Frame  4  from  the  menu  to  start  this  exercise. 


Framg  PYsrvigw: 

This  frame  is  designed  to  permit  you  to  focus  on  processing  the  Initial  Contact  (IC)  from  aircraft 
entering  the  sector.  Aircraft  in  this  scenario  will  approach  the  boundary  and  enter  your  sector. 
You  will  accept  the  offered  handoffs  and  respond  to  IC  failures. 


Comptets-thg  FQilQwing 

BE  SURE  TO  LOG  ON  TO  '^ITL  COMMON  CONSOLE  BEFORE  BEGINNING  THESE 
EXERCISES! 

1.  Observe  Normal  Initial  Contact  Procedure 

-  Accept  handoffs  for  several  aircraft. 

-  Observe  the  transfer  of  Data  Link  eligibility  to  your  sector  in  the  FDB.  Note  that  the  IC  is 
transparent  —  no  display  indications  when  correct  assigned  altitude  is  downlinked  with  the  TOC 
wilco. 


2.  Process  Aircraft  Failure  to  Report 

-  Identify  several  aircraft  being  handed  off  to  your  sector  to  the  simulation  pilot  and  tell  him  not  to 
append  his  assigned  altitude  when  wilcoing  the  TOCs. 

-  Observe  "NALT"  display  in  FDB. 

-  Clear  the  NALT  using  the  delete  command  for  some  aircraft,  and  by  updating  the  assigned 
altitude  or  uplinking  an  assigned  altitude  for  others. 


3.  Process  a  EHscrepancy  in  Reported  and  Flight  Plan  Altitudes 


-  Identify  several  aircraft  being  handed  off  to  your  sector  to  the  simulation  pilot  and  tell  him  to 
send  an  erroneous  altitude  with  his  wilco  to  the  TCXTs. 

-  Observe  the  error  display  in  the  FOB. 

-  Clear  the  error  using  the  delete  command  for  some  aircraft,  and  by  updating  the  assigned 
altitude  or  uplinking  an  assigned  altitude  for  others. 


When  you  have  completed  this  exercise,  type  "EXIT"  to  end  the  exercise  frame.  Individually 
answer  all  questions  in  this  section  of  the  review  booklet,  then  turn  to  the  next  service  description. 


INITIAL  CONTACT  REVIEW  QUESTIONS: 

1.  Does  the  description  accurately  represent  the  design  and 
operation  of  the  IC  service  that  you  examined  on  the  ISSS 
prototype? 

_  YES,  THE  DESCRIPTION  IS  CORRECT 


_  NO,  IT  DOESN'T  MATCH 

Describe  those  aspects  of  the  description  that 
did  not  match  your  observations  -- 
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2.  Is  the  yellow  "NALT"  display  in  the  data  block  adequate  to 
capture  the  controller's  attention  when  the  flight  deck  fails 
to  downlink  a  reported  assigned  altitude  with  the  wilco  to  the 
TOC? 


3.  Are  the  timesharing  altitude  report  and  the  flight 
plan  altitudes  followed  by  a  yellow  "E"  in  the  data  block 
display  adequate  to  capture  the  controller's  attention  when 
there  is  a  discrepancy? 


# 


4.  Are  the  two  procedures  for  clearing  the  "NALT"  and  altitude 
discrepancy  displays  appropriate  and  adequate?  (i.e.  slewing 
to  the  FDB  or  updating  altitude) 


5.  What  should  be  done  to  improve  the  design  of  the  IC  service  as 
implemented  in  the  ISSS  prototype?  Include  any  changes 
suggested  by  your  answers  to  questions  2-4. 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 

CHANGES  ARE  DESIRABLE  OR  NEEDED 


_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  ~  NO 
CHANGES  ARE  NEEDED,  612  THE  FOLLOWING  WOULD  BE 
DESIRABLE; 


_  THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  - 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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EXERCISE  FRAME  5 
MENU  TEXT 


Read  the  entire  Menu  Text  service  description. 

Then,  select  Frame  5  from  the  menu  to  start  this  exercise. 


Rame  Overview: 

This  frame  is  designed  to  permit  you  to  focus  on  sending  uplinks  from  the  menu  and  on  inputs 
used  to  control  and  modify  the  menu.  Aircraft  in  this  scenario  will  be  moving  through  your  sector, 
and  you  will  not  be  required  to  accept  or  offer  handofrs. 


Complete  the  Following  Exercises: 

1.  Send  Altitude  Messages  from  the  Menu 

-  Send  several  altitude  assignment  and  interim  altitude  messages  by  menu  selection  —  tiy  both 
hackball  and  keyboard  entry  methods. 

•  Observe  FDB  and  Status  List  message  content  displays  and  status  changes. 


2.  Send  Text  Messages  from  the  Menu 

-  Send  several  text  messages  from  the  menu  --  try  both  trackball  and  keyboard  entry  methods. 

-  Observe  FDB  and  Status  List  message  content  displays  and  status  changes. 

-  Identify  an  aircraft  and  tell  the  simulation  pilot  to  respond  UNABLE  to  a  text  message  from  the 
menu. 

-  Observe  unable  message  provided  in  status  list  only. 


3.  Temporary  and  Permanent  Modifications  to  an  Altitude  Menu  Item 

-  Select  an  altitude  item,  make  a  one-time  modification  to  the  altitude  value  and  send  the  message. 

-  Observe  the  FDB  and  Status  list  displays  for  the  new  uplinked  value. 


-  Note  that  no  change  is  made  in  the  displayed  menu  item. 

-  Select  another  altitude  item  and  make  a  permanent  change  to  the  altitude  value. 

-  Observe  change  in  displayed  menu. 

-  Return  value  to  adapted  value  using  menu  default  command 

4.  Control  Menu 

-  Move  the  menu  to  a  new  location  on  the  situation  display. 

-  Suppress  the  menu  and  retrieve  it  back  to  the  display. 

When  you  have  completed  this  exercise,  type  "EXIT"  to  end  the  exercise  frame.  Individually 
answer  all  questions  in  this  section  of  the  review  booklet,  then  turn  to  the  next  service  description. 
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MENU  TEXT  REVIEW  QUESTIONS; 


1.  Does  the  description  accurately  represent  the  design  and 
operation  of  the  Menu  Text  function  that  you  examined  on  the 
ISSS  prototype? 


_  YES,  THE  DESCRIPTION  IS  CORRECT 

_  NO,  IT  DOESNT  MATCH 

Describe  those  aspects  of  the  description  that 
did  not  match  your  observations  -- 


2.  For  altitude  items,  the  menu  includes  an  indicator 
identifying  those  items  that  are  interim  altitudes  (QQ)  and 
those  that  are  assigned  altitudes  (QZ).  Are  these 
necessary?  If  so,  should  QQ  and  Q2!^  or  some  other  indicators, 
be  used  (e.g.  lA  and  AA). 


3.  When  a  text  message  is  uplinked  from  the  menu,  no  data  block 
display  of  message  type  and  transaction  status  is  provided. 

Is  a  data  block  display  needed? 


4.  The  status  list  identifies  message  content  using  the  menu  item 
identifier  (e.g.  MT  A).  Does  this  provide  sufficient  feedback 
about  the  message  that  was  sent? 


5.  Do  you  foresee  any  significant  possibility  that  controllers 
will  make  undetected  errors  when  uplinking  altitudes  using 
the  menu  function?  If  yes,  please  explain. 


6.  What  should  be  done  to  improve  the  design  of  the  Menu  Text 
function  as  implemented  in  the  ISSS  prototype?  Include  any 
changes  suggested  by  your  answers  to  questions  2-5. 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 

CHANGES  ARE  DESIRABLE  OR  NEEDED 


_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 

CHANGES  ARE  NEEDED.  fiUI  THE  FOLLOWING  WOULD  BE 
DESIRABLE;  (describe) 


_  THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  - 

THE  FOLLOWING  CHANGES  MUST  BE  MADE: 


4 
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EXERCISE  FRAME  6 


COMMUNICATIONS  BACKUP 

Read  the  entire  Communications  Backup  service  description. 
Then,  select  Frame  6  from  the  menu  to  start  this  exercise. 


Frame  Overview: 

This  frame  is  designed  to  permit  you  to  focus  on  composing  and  sending  messages  using  the 
communications  backup  service.  Aircraft  in  this  scenario  will  be  moving  through  your  sector,  and 
you  will  not  be  required  to  accept  or  offer  handoffs. 


Coipplete  the  Following  Exercises; 

1.  Send  Communications  Backup  Message 

-  Compose  and  send  sveral  communications  backup  messages. 

•  Observe  content  and  status  information  provided  in  Status  List 
only. 


When  you  have  completed  this  exercise,  type  "EXIT"  to  end  the  exercise  frame.  Individually 

answer  all  questions  in  this  section  of  the  review  booklet.  * 
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COMMUNICATIONS  BACKUP  REVIEW  QUESTIONS: 


1.  Does  the  description  accurately  represent  the  design  and 
operation  of  the  Communications  Backup  service  that  you 
examined  on  the  ISSS  prototype? 

_  YES,  THE  DESCRIPTION  IS  CORRECT 


_  NO,  IT  DOESN’T  MATCH 

Describe  those  aspects  of  the  description  that 
did  not  match  your  observations  -- 


2.  No  data  block  display  of  message  content  or  transaction  status 
are  provided  for  communications  backup.  Are  these  needed  or 
are  the  Status  list  displays  sufficient? 


3.  Is  the  truncated  version  of  the  message  provided  in  the  status 
list  an  adequate  indication  of  the  message's  content? 


4.  What  should  be  done  to  improve  the  design  of  the 
Communications  Backup  service  as  implemented  in  the  ISSS 
prototype?  Include  any  changes  suggested  by  your  answer  to 
questions  2  and  3. 

_ THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 

CHANGES  ARE  DESIRABLE  OR  NEEDED 


_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  -  NO 
CHANGES  ARE  NEEDED,  fiLH  THE  FOLLOWING  WOULD  BE 
DESIRABLE:  (describe) 
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_ THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  - 

THE  FOLLOWING  CHANGES  MUST  BE  MADE; 

SWAT  WORKLOAD  RATINGS 

After  each  test  run,  you  will  be  asked  to  complete  a  rating  of  the  workload  that  you  actually 
experienced  while  controlling  traffic.  The  scale  that  you  will  use  to  make  these  estimates  is  known 
as  SWAT  (Subjective  Workload  Assessment  Technique).  SWAT  was  developed  as  a  method  for 
coUecting  quantified  subjective  data  on  how  hard  a  person  feels  he  or  she  had  to  work  when 
performing  different  tasks  or  when  using  different  procedures  and  equipment  to  perform  duties. 

If  you  examine  the  SWAT  rating  scale,  you  will  notice  that  SWAT  defines  workload  in  terms  of  a 
combination  of  three  different  dimensions  that  contribute  to  the  subjective  feeling  of  "woiking 
hard".  A  workload  rating  in  SWAT  is  accomplished  by  selecting  a  "1",  "2"  or  "3"  on  EACH  of  the 
three  scales  representing  the  dimensions  of  TIME  LOAD,  MENTAL  EFFORT,  and 
PSYCHOLOGICAL  STRESS. 

Each  of  these  dimensions  and  their  levels  are  described  below: 

TIME  LOAD 

Time  Load  refers  to  the  fraction  of  the  total  time  that  you  are  busy.  When  Time  Load  is  low, 
sufficient  time  is  available  to  complete  all  of  your  mental  woric  with  some  time  to  spare.  As  Time 
Load  increases,  spare  time  drops  out  and  some  aspects  of  performance  overlap  and  interrupt  one 
another.  This  overlap  and  interruption  can  come  from  performing  more  than  one  task  or  from 
different  aspects  of  performing  the  same  task.  At  high  levels  of  Time  Load,  many  things  occur 
simultaneously,  you  are  busy,  and  interruptions  are  very  frequent. 

Time  Load  is  rated  on  the  three  point  scale  below: 

(1)  Often  have  spare  time.  Interruptions  or  overlap  among 
activities  occur  infrequently  or  not  at  all. 

(2)  Occasionally  have  spare  time.  Interruptions  or  overlap 
among  activities  occur  frequently. 

(3)  Almost  never  have  spare  time.  Interruptions  or  overlap 
among  activities  are  very  frequent,  or  occur  all  the 
time. 
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MENTAL  EFFORT  LOAD 

As  described  above.  Time  Load  refers  to  the  amount  of  time  one  has  available  to  perform  a  task 
or  tasks.  In  contrast.  Mental  Effort  Load  is  an  index  of  the  amount  of  attention  or  mental  effort 
required,  regardless  of  the  number  of  tasks  to  be  performed  or  any  time  limitations.  When  Mental 
Effort  Load  is  low,  the  concentration  and  attention  required  by  a  task  is  minimal  and  performance 
is  nearly  automatic.  As  the  demand  for  mental  effort  increases  due  to  task  complexity  or  the 
amount  of  information  which  must  be  dealt  with  in  order  to  perform  adequately,  the  degree  of 
concentration  and  attention  required  increases.  High  Mental  Effort  Load  demands  total  attention 
or  concentration  due  to  task  complexity  or  the  amount  of  information  that  must  be  processed. 

f  Mental  Effort  Load  is  rated  using  the  three  point  scale  below: 

^  (1)  Very  little  conscious  mental  effort  or  concentration 

required.  Activity  is  almost  automatic,  requiring  little  or 
no  attention. 

(2)  Moderate  conscious  mental  effort  or  concentration 
required.  Complexity  of  activity  is  moderately  high 
due  to  uncertainty,  unpredictability,  or  unfamiliarity. 

Considerable  attention  required. 

(3)  Extensive  mental  effort  and  concentration  are 
necessary.  Very  complex  activity  requiring  total  attention. 

PSYCHOLOGICAL  STRESS  LOAD 

Psychological  Stress  Load  refers  to  the  contribution  to  total  workload  of  any  conditions  that 
produce  anxiety,  frustration,  or  confusion  while  performing  a  task  or  tasks.  At  low  levels  of 
stress,  one  feels  relatively  relaxed.  As  stress  increases,  confusion,  anxiety,  or  frustration  increase 
and  greater  concentration  and  determination  are  required  to  maintain  control  of  the  situation. 

^  Psychological  Stress  Load  may  be  rated  on  the  three  point  scale  below: 

(1)  Little  confusion,  risk,  frustration,  or  anxiety  exists 

*  and  can  be  easily  accommodated. 

(2)  Moderate  stress  due  to  confusion,  frustration,  or 
anxiety  noticeably  adds  to  workload.  Significant 
conqiensation  is  required  to  maintain  adequate 
performance. 
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(3)  High  to  very  intense  stress  due  to  confusion, 
frustration,  or  anxiety.  High  to  extreme 
determination  and  self-control  required. 

Each  of  the  three  dimensions  just  described  contribute  to  workload  during  performance  of  a  task 
or  group  of  tasks.  Note  that  although  all  three  factors  may  be  correlated,  they  need  not  be.  For 
example,  one  can  have  many  tasks  to  perform  in  the  time  available  (high  Time  Load)  but  the  tasks 
may  require  little  concentration  (low  Mental  Effort  Load).  Likewise,  one  can  be  anxious  and 
frustrated  (high  Stress  Load)  and  have  plenty  of  spare  time  between  relatively  simple  tasks.  Since 
the  three  dimensions  contributing  to  workload  are  not  necessarily  correlated,  please  treat  each 
dimension  individually  and  give  independent  assessments  of  the  Time  Load,  Mental  Effort  Load, 
and  Psychological  Stress  Load  that  you  experienced  during  each  test  run. 

I 

The  form  that  you  will  be  using  to  make  your  SWAT  ratings  during  the  Data  Link  test  sessions  is 

shown  on  an  attached  page.  Note  that  the  descriptions  for  each  level  of  time,  effort  and  stress  , 

load  have  been  removed  to  save  space.  Should  you  need  to  review  these  descriptions  during 

testing,  a  copy  of  the  full  scale  will  be  available  at  all  times. 

SWAT  SCALE  DEVELOPMENT  CARD  SORT 

Now  that  you  are  familiar  with  the  SWAT  rating  scale,  there  is  one  last  procedure  that  must  be 
completed  before  testing  can  begin.  This  procedure  is  a  card  sorting  task  that  will  allow  us  to 
interpret  your  SWAT  workload  ratings. 

One  of  the  most  important  features  of  SWAT  is  its  unique  scoring  system.  The  developers  of 
SWAT  recognized  that  different  people  have  different  conceptions  of  how  the  time,  effort  and 
stress  dimensions  combine  to  produce  an  overall  inq)ression  of  low  and  high  workload.  Because 
of  these  differences,  a  special  card  sorting  procedure  is  used  in  SWAT  to  defme  a  distinctive 
workload  scale  for  each  person.  This  individualized  scale  greatly  improves  our  ability  to 
accurately  interpret  the  actual  workload  ratings  that  you  will  be  making  during  the  test  sessions. 

In  order  to  develop  your  individual  scale,  we  need  information  from  you  regarding  the  amount  of 
workload  that  you  feel  is  produced  by  various  combinations  of  the  three  levels  on  the  time,  effort 
and  stress  dimensions.  We  get  this  information  by  having  a  person  rank  order  a  set  of  cards.  v 

Each  card  contains  a  different  combination  of  the  levels  of  time  load,  mental  effort  load,  and  stress 
load.  Since  there  are  three  dimensions,  and  each  dimension  has  three  levels,  there  are  27  cards  in 
the  deck  that  you  will  be  sorting.  Your  job  will  be  to  sort  the  cards  so  that  they  are  ranked 
according  to  the  level  of  workload  represented  by  each  card.  Thus,  the  first  card  in  the  deck  will 
represent  the  lowest  workload  and  the  last  card  will  represent  the  highest  workload. 

In  completing  your  card  sorts,  please  consider  the  workload  imposed  on  a  person  by  the 
combination  represented  in  each  card.  Arrange  the  cards  from  the  lowest  workload  condition 
through  the  highest  condition.  You  may  use  any  strategy  you  choose  in  rank  ordering  the  cards. 
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One  strategy  that  proves  useful  is  to  arrange  the  cards  into  a  number  of  preliminary  stacks 
representing  "High",  "Moderate",  and  "Low"  workload.  Individual  cards  can  be  exchanged 
between  stacks,  if  necessary,  and  then  rank  ordered  within  stacks.  Stacks  can  then  be  recombined 
and  checked  to  be  sure  that  they  represent  your  ranking  of  lowest  to  highest  workload.  However, 
the  choice  of  strategy  is  up  to  you  and  you  should  choose  the  one  that  works  best  for  you. 

There  is  no  "school  solution"  to  this  problem.  There  is  no  correct  order.  The  correct  order  is 
what,  in  your  judgment  best  describes  the  progression  of  workload  from  lowest  to  highest  for  a 
general  case  rather  than  any  specific  event.  That  judgment  differs  for  each  of  us.  The  letters  you 
see  on  the  back  of  the  cards  are  to  allow  us  to  arrange  the  cards  in  a  previously  randomized 
sequence  so  that  everyone  gets  the  same  order.  If  you  examine  your  deck  you  will  see  the  order 
»  on  the  back  runs  from  A  through  Z  and  then  ZZ. 

^  Please  remember: 

(1)  The  card  sort  is  being  done  so  that  a  workload  scale  may  be  developed  for  you.  This  scale 
will  have  a  distinct  workload  value  for  each  possible  combination  of  Time  Load,  Mental  Effort 
Load,  and  Psychological  Stress  Load.  The  following  example  demonstrates  the  relationship 
between  the  card  sort  and  the  resulting  workload  scale; 

TIME  EFFORT  STRESS  WORKLOAD  SCALE 

1  1  I  -  0.0 


3  3  3  -  100.0 

Note  that  other  than  the  fact  that  a  1-1-1  will  always  represent  the  lowest  workload  and  that  a  3- 
3-3  will  always  represent  the  highest  workload,  the  remaining  cards  could  occur  in  a  number  of 
orders.  Your  order  will  depend  on  how  you  weight  the  importance  of  Time,  Effort  and  Stress 
diinensions. 

(2)  When  performing  the  card  sorts,  use  the  descriptors  printed  on  the  cards.  Please  remember 
not  to  sort  the  cards  based  on  one  particular  task.  Sort  the  cards  according  to  your  general  view 
of  w(»kload  and  how  important  you  consider  the  dimensions  of  Time,  Mental  Effort,  and 
Psychological  Stress  Load  to  be  when  you  think  of  high  and  low  workload  experiences. 

(3)  A  SWAT  rating  for  any  situation  consists  of  one  number  from  each  of  the  three  dimensions. 
For  example,  a  possible  SWAT  rating  is  1-2-2.  This  represents  a  1  for  Time  Load,  a  2  for  Mental 
Effort  Load,  and  a  2  for  Psychological  Stress  Load. 
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(4)  We  are  not  asking  for  your  preference  concerning  Time,  Mental  Effort,  and  Psychological 
Stress  Load.  Some  people  may  prefer  to  be  "busy”  rather  than  "idle"  in  either  Time  Load,  Mental 
Effort  Load,  or  Psychological  Stress  Load  dimension.  We  are  not  concerned  with  this  preference. 
We  Med  information  on  how  the  three  dimensions  and  the  three  levels  of  each  one  will  affect  the 
level  of  workload  as  you  see  it.  You  may  prefer  a  2-1-1  situation  instead  of  a  1-1-1  situation. 
However,  you  should  still  realize  that  the  1-1-1  situ^on  imposes  less  workload  on  you  and 
leaves  a  greater  reserve  capacity. 

The  sorting  will  probably  take  30  minutes  to  an  hour.  Please  feel  free  to  ask  questions  at  any 
time. 
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r 


SWAT  WORKLOAD 

TEST  RUN _  POSITION  . 

DL  /  VOICE  _  PVD  /  ISSS 


Rate  the  workload  that  you  actually  axparianead 
controlling  traffic  during  the  teat  run  |uat  completed. 

For  each  of  the  SWAT  dimenalona  of  TIME  LOAD,  EFFORT 
and  STRESS,  place  an  on  the  appropriate  line  to 
indicate  the  level  that  you  experienced  ranging  from 
»  1  (low)  to  3  (high) 


12  3 


TIME  LOAD 

MENTAL  EFFORT 


STRESS 


Please  describe  any  events  or  experiences  that  may  have 
affected  your  workload  during  this  test  run: 


SWAT  WORKLOAD  RATING  FORM 
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RATER  NAME 


CONTROLLER  EVALUATION 
DATA  LINK  ISSS  SERVICES 

i 

FINAL  RATINGS  , 


The  fonns  in  this  booklet  should  be  completed  after  you  have  finished  all  four  test  runs  of  the  full 
scale  simulation. 

Their  are  two  sets  of  rating  forms.  The  first  set  will  ask  you  to  make  some  projective  estimates  of 
the  way  in  which  Data  Link  will  affect  the  controller  and  the  ATC  system  in  an  actual  operational 
inqilementation. 

The  second  set  of  ratings  will  allow  you  to  make  some  overall  quantitative  judgments  about  each 
of  the  ISSS  Data  Link  services  as  they  have  been  implemented  for  this  study. 

Please  read  the  instructions  preceding  each  set  of  ratings  carefully  before  completing  the  rating 
scales. 


t 
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PART  1;  PROJECTIVE  COMPARISONS 


In  the  following  three  questions  you  will  be  asked  to  use  your  simulation  experiences  to  make 
some  projective  judgements  about  how  you  think  Data  Link  and  the  features  of  existing  and 
future  workstations  would  affect  the  controller  and  the  ATC  system  in  an  actual  operational 
implementation. 

To  do  this,  you  will  make  all  possible  comparisons  of  the  four  combinations  of  communication 
system  and  controller  workstation  that  were  used  in  the  simulation  runs.  These  comparisons  will 
be  made  on  four  dimensions:  controller  workload,  ATC  system  safety,  ATC  system  capacity,  and 
controller  efficiency/productivity. 

For  each  dimension,  the  six  possible  pairs  are  presented  on  opposite  ends  of  a  line  of  spaces.  For 
each  pair,  place  an  "X"  in  the  space  which  best  describes  your  view  of  which  of  the  two 
combinations  of  communication  system  and  workstation  is  higher  on  the  dimension  being 
addressed.  If  the  pair  does  not  differ,  place  the  "X"  in  the  "Equal"  space. 


Remember,  other  than  the  current  Host/PVD  system  with  voice  communication  with  which  you 
have  direct  c^rational  experience,  you  are  making  projective  judgments  about  the  effects  of  these 
combinations  in  a  future  operational  setting.  Thus,  you  should  assume  normal  operational  levels 
of  controller  training  and  airspace  familiarity. 


The  following  abbreviations  are  used  to  specify  four  combinations  on  the  comparison  scales: 

PVDA^  -  Host/PVD  system.  Voice-only  communications 

PVD/V&D  -  Host/PVD  system.  Voice  and  Data  Link  communications 

ISSS/V  -  ISSS  system.  Voice-only  communications 

ISSS/V&D  -  ISSS  system.  Voice  and  Data  Link  communications 


■ 


1)  Compare  each  of  the  foJlowing  pairs  of  workstation  and  communication  conditions  in  terms  of 
the  way  in  which  you  feel  they  currently  impact,  or  will  impact,  CONTRQl  1  FR  WORKLOAD  in 
an  operational  implementation. 


<-Higher  Workload 

Higher  Workload— > 

Much 

Somewhat 

Somewhat  Much 

Higher 

Higher  Equal 

Higher  Higher 

PVD/V 

isss/y 

PVDA^ 

PVDA^&D 

PWUfW 

ISSSA^&D 

isss/y/ 

PVDA^&D 

ISSS/V 

ISSSA'&D 

PVD/V&D 

ISSSA^&D 

* 


2)  Compare  each  of  the  following  pairs  of  workstation  and  communication  conditions  in  terms  of 
the  way  in  which  you  feel  they  currently  impact,  or  will  impact,  ATC  SYSTEM  CAPACITY  in  an 
operational  implementation. 


<-Higher  Capacity 

Higher  Cap^ity“> 

Much 

Somewhat 

Somewhat  Much 

Higher 

Higher  Equal 

Higher  Higher 

PVDA^ 

ISSSA^ 

PVDA^ 

PVDA^&D 

PVDA^ 

ISSSAV&D 

ISSSA^ 

PVDA^&D 

ISSS/V 

ISSSA^«feD 

PVDA^&D 

ISSSA^&D 
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3)  Compare  each  of  the  following  pairs  of  workstation  and  communication  conditions  in  terms  of 
the  way  in  which  you  feel  they  currently  impact,  or  will  impact,  ATC  SYSTEM  SAFETY  in  an 
operational  implementation. 


<— Higher  Safety  Higher  Safety— > 


Much  Somewhat  Somewhat  Much 
Higher  Higher  Equal  Higher  Higher 


PVDA^ 

ISSSA^ 

PVDA^ 

PVD/V&D 

PVDA^ 

ISSSA^&D 

ISSSA^ 

PVDA/&D 

ISSSA^ 

ISSSA^&D 

PVDA^&D 

ISSSA^& 

4)  Compare  each  of  the  following  pairs  of  workstation  and  communication  conditions  in  terms  of 
the  way  in  which  you  feel  they  currently  impact,  or  will  impact,  CONTROLLER 
EFFICIENCY/PRODUCnVITY  in  an  operational  implementation. 

<-Higher  E/P  Higher  E/P-> 

Much  Somewhat  Somewhat  Much 

Higher  Higher  Equal  Higher  Higher 


PVDA^ 

ISSSA^ 

PVDA^ 

PVDA^&D 

PVDAV 

ISSSA^&D 

ISSSA^ 

PVD/V&D 

ISSSA^ 

ISSS/V&D 

PVDA^&D 

ISSS/V& 
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PART  2;  ISSS  CANDIDATE  SERVICE  EVALUATIONS 


Each  of  the  following  five  forms  is  dedicated  to  one  of  the  ISSS  Data  Link  service  designs  that 
were  tested  in  this  study.  Two  rating  scales  are  provided  on  each  form  to  evaluate  the  services  as 
implemented  for  this  study; 

OPERATIONAL  EFFECTIVENESS  AND  SUITABILITY 

The  first  scale  on  each  form  asks  for  a  rating  of  operational  effectiveness  and  suitability.  To 
evaluate  this  factor,  you  should  consider  the  degree  to  which  each  service  implementation  could 
effectively  accon:q>lish  the  task  it  was  designed  to  perform.  Thus,  you  are  deciding  whether  each 
design  provides  all  of  the  functions  and  capabilities  that  will  be  needed  to  meet  operational 
requirements  in  a  field  setting.  Follow  the  instructions  on  the  form  when  completing  the  rating 
scale. 

CONTROLLER  ACCEPTANCE  AND  PREFERENCE 

The  second  scale  on  each  form  asks  for  a  rating  of  the  acceptability  of  the  service  design  to 
controllers.  To  evaluate  this  factor,  consider  the  extent  to  which  the  displays,  inputs  and 
procedures  for  the  service  would  be  usable  by  field  controllers  and  compatible  with  their  styles  of 
controlling  air  traffic.  Follow  the  instructions  on  the  form  when  conq)leting  the  scale. 

PLEASE  NOTE: 

When  making  your  ratings,  remember  that  operational  effectiveness/suitability  and  controller 
acceptance/preference  should  be  considered  independently.  Although  the  two  dimensions  may 
vary  together,  a  service  design  could  provide  all  the  functions  needed  to  meet  operational 
requirements  and  still  be  poorly  suited  to  the  controller's  way  of  doing  his  job.  Likewise,  a 
design  could  be  easy  to  use,  but  have  limitations  which  prevent  it  from  covering  all  operational 
situations. 


% 


I 


■> 
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Altitude  Assignment 


Use  the  scales  below  to  rate  the  ISSS  service  indicated 
ebove.  On  the  first  scale,  check  the  box  if  this  service 
Is  unsuitable  for  operational  use.  If  the  service  can  meet 
some,  or  all  operational  requirementa,  check  the  space  below 
the  number  that  best  describee  its  effectiveness. 

OPERATIONAL  EFFECTIVENESS  /  SUITABILITY 


» 

T 


Highly 

Effective 


I 

1  2 


Meets  Most 
Operational 
Requirements 

I 

3  4  5 

—  -  -  -  - 

Operationally 

Suitable 


6 


Minimally 

Effective 


I 

7 


On  this  scale,  regardless  of  the  service's  effectiveness, 
check  the  box  if  the  way  in  which  the  service  Is  designed 
would  be  completely  unacceptable  to  controllers,  if  the 
service  design  is  acceptable,  cheek  the  space  below  the 
number  that  best  describes  your  preference  for  the  design. 

CONTROLLER  ACCEPTANCE  /  PREFERENCE 


i 


r 


Highly 

Preferred 

i 


Moderately 

Preferred 

I 


Acceptable, 
But  Not 
Preferred 

I 


1  2  3  4  5  6  7 


t 

Completely 

Unacceptable 


Please  comment  on  your  ratings  on  the  back  of  this  page. 

OPERATIONAL  EFFECTIVENESS/SUITABILITY  AND  CONTROLLER 
ACCEPTANCE/PREFERENCE  RATING  FORM 
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